On Sun, 14 Jan 2024 19:40:46 +0000, bart <bc@freeuk.com> wrote in
<uo1dbu$img2$1@dont-email.me>:

> Started a new thread as the last one went somewhat off-topic regarding
> 'CPP tags'.
>
> Everyone is getting tired of me mouthing off about Make and friends, and
> I'm fed up of not being believed when I talk about the problems it
> introduces.
>
> I thought I'd try one more attempt at finding a small C project that
> used make to see if it really was as bad as I was saying.
>
> There is a small test file I have called piet.c, an esoteric language
> interpreter. I couldn't find the original project but there is one
> called npiet.c (https://www.bertnase.de/npiet/).
>
> It contains these files:
>
> c:\xxx\npiet-1.3f>dir 09/08/2020 12:41 5,574 ChangeLog
> 26/06/2004 16:53 461 config.h.in 09/08/2020 13:18
> 140,516 configure 05/08/2011 19:19 584
> configure.in 06/06/2004 17:48 17,984 COPYING 09/08/2020
> 12:41 <DIR> examples 09/08/2020 12:17 <DIR>
> foo 06/06/2004 12:25 4,771 install-sh 09/08/2020
> 13:18 44 Makefile 04/12/2014 20:59
> 2,743 Makefile.in 05/08/2011 21:26 2,116
> npiet-foogol.1 09/08/2020 13:18 98,071 npiet-foogol.c
> 19/11/2014 19:17 45,555 npiet-foogol.y 04/08/2011
> 21:14 4,446 npiet.1 09/08/2020 12:35 68,150
> npiet.c 29/01/2005 19:29 17,801 npietedit 26/09/2004
> 21:53 1,064 npietedit.1 27/01/2014 17:24
> 1,436 README.npiet
>
> There is a makefile (which only contains the message to run ./configure)
> and a configure script.
>
> If try and do make under Windows, it actually does some tests,
> concluding that I don't have gcc, cc or cl installed, and fails on 'No C
> Compiler'.
>
> If I run this 4800-line script under WSL, it produces a 140-line
> makefile. The makefile tries to build 3 programs, the main 'npiet', and
> two more, but those have dependencies that will fail even under WSL.
>
> Actually, 'npiet' is successfully created, but that fact is lost amongst
> all the errors.
>
> Now that I have a makefile, could it work under Windows for building
> 'npiet.exe'? Apparently not, because the makefile is Linux-specific.
>
> So, under actual Windows, both 'make' and './configure' were useless.
>
> But you will say, This is obviously for Linux, what did you expect?
>
> ===============================
>
> Here I will reveal a secret: as soon as I saw that list of files, and
> saw that make required configure, I tried this anyway:
>
> c:\xxx\npiet-1.3f> mcc npiet Compiling npiet.c to npiet.exe
>
> It just worked! And it seems to run:
>
> c:\xxx\npiet-1.3f> npiet examples\nfib.ppm 0
> 1
> 1
> 2
> 3
> 5
> 8
> 13 21 34 55 89 144 233 377 610 987
>
> (The nfib.ppm file is a block of coloured pixels. You can see examples
> at the link. I've no idea how it works; I just use these as test
> programs.)
>
> Apparently it works on Windows just fine, no thanks to the Readme,
> makefile and configure files.
>
> ===============================
>
> So, I ask again, why this obsession that C developers have with make and
> configure files? It's taken a simple, one-file program and made it
> impossible to build on my favoured OS, if you were to follow the make
> route.
>
> Actually, if I look inside npiet.c, it does explain how to build the
> program with a bare compiler. This is also where I put build info when I
> distribute C programs. To hell with make.

Take a look in your Makefile for other make rules. You
missed another couple of files in the directory, which appear
to be related: npiet-foogol.c and npiet-foogol.y.

The .y is for lex(1) and yacc(1), for which GNU
has flex and bison. What does your all-inclusive
C compiler do with .y files?

Also, if you don't know what it does, try running "man npiet.1" or
"man npiet-foogol.1" in your WSL instance -- the *.1 files are
the man pages.

Finally, it's possible the developer just wanted to try out
autoconf. Can't really know what they were thinking...

--
-v

On 15/01/2024 21:24, vallor wrote:
> On Sun, 14 Jan 2024 19:40:46 +0000, bart <bc@freeuk.com> wrote in
> <uo1dbu$img2$1@dont-email.me>:
>
>> Started a new thread as the last one went somewhat off-topic regarding
>> 'CPP tags'.
>>
>> Everyone is getting tired of me mouthing off about Make and friends, and
>> I'm fed up of not being believed when I talk about the problems it
>> introduces.
>>
>> I thought I'd try one more attempt at finding a small C project that
>> used make to see if it really was as bad as I was saying.
>>
>> There is a small test file I have called piet.c, an esoteric language
>> interpreter. I couldn't find the original project but there is one
>> called npiet.c (https://www.bertnase.de/npiet/).
>>
>> It contains these files:
>>
>> c:\xxx\npiet-1.3f>dir 09/08/2020 12:41 5,574 ChangeLog
>> 26/06/2004 16:53 461 config.h.in 09/08/2020 13:18
>> 140,516 configure 05/08/2011 19:19 584
>> configure.in 06/06/2004 17:48 17,984 COPYING 09/08/2020
>> 12:41 <DIR> examples 09/08/2020 12:17 <DIR>
>> foo 06/06/2004 12:25 4,771 install-sh 09/08/2020
>> 13:18 44 Makefile 04/12/2014 20:59
>> 2,743 Makefile.in 05/08/2011 21:26 2,116
>> npiet-foogol.1 09/08/2020 13:18 98,071 npiet-foogol.c
>> 19/11/2014 19:17 45,555 npiet-foogol.y 04/08/2011
>> 21:14 4,446 npiet.1 09/08/2020 12:35 68,150
>> npiet.c 29/01/2005 19:29 17,801 npietedit 26/09/2004
>> 21:53 1,064 npietedit.1 27/01/2014 17:24
>> 1,436 README.npiet
>>
>> There is a makefile (which only contains the message to run ./configure)
>> and a configure script.
>>
>> If try and do make under Windows, it actually does some tests,
>> concluding that I don't have gcc, cc or cl installed, and fails on 'No C
>> Compiler'.
>>
>> If I run this 4800-line script under WSL, it produces a 140-line
>> makefile. The makefile tries to build 3 programs, the main 'npiet', and
>> two more, but those have dependencies that will fail even under WSL.
>>
>> Actually, 'npiet' is successfully created, but that fact is lost amongst
>> all the errors.
>>
>> Now that I have a makefile, could it work under Windows for building
>> 'npiet.exe'? Apparently not, because the makefile is Linux-specific.
>>
>> So, under actual Windows, both 'make' and './configure' were useless.
>>
>> But you will say, This is obviously for Linux, what did you expect?
>>
>> ===============================
>>
>> Here I will reveal a secret: as soon as I saw that list of files, and
>> saw that make required configure, I tried this anyway:
>>
>> c:\xxx\npiet-1.3f> mcc npiet Compiling npiet.c to npiet.exe
>>
>> It just worked! And it seems to run:
>>
>> c:\xxx\npiet-1.3f> npiet examples\nfib.ppm 0
>> 1
>> 1
>> 2
>> 3
>> 5
>> 8
>> 13 21 34 55 89 144 233 377 610 987
>>
>> (The nfib.ppm file is a block of coloured pixels. You can see examples
>> at the link. I've no idea how it works; I just use these as test
>> programs.)
>>
>> Apparently it works on Windows just fine, no thanks to the Readme,
>> makefile and configure files.
>>
>> ===============================
>>
>> So, I ask again, why this obsession that C developers have with make and
>> configure files? It's taken a simple, one-file program and made it
>> impossible to build on my favoured OS, if you were to follow the make
>> route.
>>
>> Actually, if I look inside npiet.c, it does explain how to build the
>> program with a bare compiler. This is also where I put build info when I
>> distribute C programs. To hell with make.
>
> Take a look in your Makefile for other make rules.

Note: I work on Windows. This stuff only works on systems like Linux.

The makefile doesn't even exist until I go through the configure step.

> You
> missed another couple of files in the directory, which appear
> to be related: npiet-foogol.c and npiet-foogol.y.
>
> The .y is for lex(1) and yacc(1), for which GNU
> has flex and bison. What does your all-inclusive
> C compiler do with .y files?

The project comprises 3 programs:

npiet.c This is a standalone program with no dependencies. It
is the one I want to run.

npietedit.c This needs TCL/TK, which I don't have on my WSL, and
I'm not interested in getting

npiet-foogol.c This one depends on a library called 'GD' which I
don't have.

This last one I believe is generated from the .y file. If I hide it, it
needs to generate it using 'bison'. I don't have that either.

The 'man' stuff is another Linux thing. (groff looks to turn .1 files
into PostScript. Manually using the invocation in the makefile, it
reports that 'html' is an invalid device).

So the configure/make stuff tries to do too much, with two many points
of failure. It means it will fail on two of those three programs because
of dependencies which it does not attempt to fix.

The error reporting however is chaotic: there is no summary of what
worked and what didn't.

So, it is attempting to build multiple applications with assorted
dependencies and processing help files or whatever.

My C compiler ... compiles .c files into a .exe or .dll file. It is
focused on that task.

It will not attempt to install anything. Or generate documentation. That
would be done at another level.

This is a clear demarcation between basic compilation and everything
else, that is missing from the make solution.

At the very least, the makefile could have used sub-makefiles to build
each of the three programs with its own dedicated script.

That could have allowed me to directly invoke the script for the main
npiet.c program, even on Windows.

Of course, any such files would actually need to exist, but they are
synthesised by the configure script, which only works on Unix-like systems.

> Also, if you don't know what it does, try running "man npiet.1" or
> "man npiet-foogol.1" in your WSL instance -- the *.1 files are
> the man pages.

> Finally, it's possible the developer just wanted to try out
> autoconf. Can't really know what they were thinking...
>

I've seen two many examples for this to be just a one-off.

I come across makefiles and the associated stuff in two main situations:

(1) There's a C library I want to build, but it's guarded by this and
mostly it doesn't workk. Even if works under WSL, I need EXE and DLL
files that work on real Windows.

(2) When I need test programs to try out my C compiler on. (Or maybe I
want to use my compiler for (1), but it's the same obstacle.)

Even if 'make' worked on Windows, my compiler is unconventional: it
doesn't use intermediate object files for example, nor a normal linker.
So I couldn't use 'make' with my compiler.

In most cases where I can finally get at the necessary information, it
turns that all that was needed was a LIST OF C SOURCE FILES. That's all.

In some cases however it is complicated by there being some essential
header, even if it only consists of 3 lines, being synthesised by the
build process. It is very frustrating.

bart <bc@freeuk.com> writes:
>On 15/01/2024 21:24, vallor wrote:

>The 'man' stuff is another Linux thing.

It predates linux by a quarter century.

$ man manpage.man

formats and displays the nroff document.

The makefile rule to build a PDF version of a man page:

%.pdf: %.man
@$(QUIET) || echo " BUILDPDF $@"
$(HUSHCOMPILE)groff -t -man $< | ps2pdf - > $@

On Tue, 16 Jan 2024 16:13:36 +0000, Scott Lurndal wrote:

> bart <bc@freeuk.com> writes:
>>On 15/01/2024 21:24, vallor wrote:
>
>>The 'man' stuff is another Linux thing.
>
> It predates linux by a quarter century.

In 1978, S. R. Bourne, of Bell Labs, wrote a paper called
"An Introduction to the UNIX shell". Section 2.10 of this
document gives a brief overview of how to access the online
version of the UNIX manual, concluding with a short shell
script that implemented the man(1) command.

> $ man manpage.man

Or, if you want to specify the section (given that some
sections have man pages with names that you might find
in other sections):

man section manpage

as in
man 1 mktemp
which describes the program "mktemp", vs
man 3 mktemp
which describes the library function "mktemp()"

The standard sections of the manual include
1 User Commands
2 System Calls
3 C Library Functions
4 Devices and Special Files
5 File Formats and Conventions
6 Games et. Al.
7 Miscellanea
8 System Administration tools and Deamons

>
> formats and displays the nroff document.
[snip]

--
Lew Pitcher
"In Skills We Trust"

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
[...]
> Or, if you want to specify the section (given that some
> sections have man pages with names that you might find
> in other sections):
>
> man section manpage
>
> as in
> man 1 mktemp
> which describes the program "mktemp", vs
> man 3 mktemp
> which describes the library function "mktemp()"

You can also type
man mktemp.1
or
man mktemp.3

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Tue, 16 Jan 2024 11:00:13 -0800, Keith Thompson wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> [...]
>> Or, if you want to specify the section (given that some
>> sections have man pages with names that you might find
>> in other sections):
>>
>> man section manpage
>>
>> as in
>> man 1 mktemp
>> which describes the program "mktemp", vs
>> man 3 mktemp
>> which describes the library function "mktemp()"
>
> You can also type
> man mktemp.1
> or
> man mktemp.3

That only works if there's a file called "mktemp.1"
(or "mktemp.3") in your local directory, at least
for the version of man(1) that I have available.

14:15 $ pwd
/home/lpitcher/tmp

14:15 $ ls -la
total 84
drwxr-xr-x 2 lpitcher users 69632 Jan 11 14:33 .
drwxr-xr-x 114 lpitcher users 12288 Jan 16 11:07 ..

14:15 $ man mktemp.3
No manual entry for mktemp.3

14:15 $ man mktemp.1
No manual entry for mktemp.1

14:15 $ man 1 mktemp | wc -l
135

14:15 $ man 3 mktemp | wc -l
74

:-)

--
Lew Pitcher
"In Skills We Trust"

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Tue, 16 Jan 2024 11:00:13 -0800, Keith Thompson wrote:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> [...]
>>> Or, if you want to specify the section (given that some
>>> sections have man pages with names that you might find
>>> in other sections):
>>>
>>> man section manpage
>>>
>>> as in
>>> man 1 mktemp
>>> which describes the program "mktemp", vs
>>> man 3 mktemp
>>> which describes the library function "mktemp()"
>>
>> You can also type
>> man mktemp.1
>> or
>> man mktemp.3
>
> That only works if there's a file called "mktemp.1"
> (or "mktemp.3") in your local directory, at least
> for the version of man(1) that I have available.

Interesting.

I have man 2.20.1 on Ubuntu, provided by the "man-db" package.
"man mktemp.1" will look up the corresponding man page in $MANPATH.
If I want to use a local file, I can use an absolute or relative path
with a '/' in it, such as "man ./mktemp.1".

[...]

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On Tue, 16 Jan 2024 11:23:52 -0800, Keith Thompson wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> On Tue, 16 Jan 2024 11:00:13 -0800, Keith Thompson wrote:
>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>> [...]
>>>> Or, if you want to specify the section (given that some
>>>> sections have man pages with names that you might find
>>>> in other sections):
>>>>
>>>> man section manpage
>>>>
>>>> as in
>>>> man 1 mktemp
>>>> which describes the program "mktemp", vs
>>>> man 3 mktemp
>>>> which describes the library function "mktemp()"
>>>
>>> You can also type
>>> man mktemp.1
>>> or
>>> man mktemp.3
>>
>> That only works if there's a file called "mktemp.1"
>> (or "mktemp.3") in your local directory, at least
>> for the version of man(1) that I have available.
>
> Interesting.

Indeed. Perhaps my environment is out of whack.

> I have man 2.20.1 on Ubuntu, provided by the "man-db" package.
> "man mktemp.1" will look up the corresponding man page in $MANPATH.
> If I want to use a local file, I can use an absolute or relative path
> with a '/' in it, such as "man ./mktemp.1".

Here's what my man(1) manual says:
DESCRIPTION
man formats and displays the on-line manual pages. If you specify sec-
tion, man only looks in that section of the manual. name is normally
the name of the manual page, which is typically the name of a command,
function, or file.

However, if name contains a slash (/) then man interprets it as
a file specification, so that you can do man ./foo.5 or even man
/cd/foo/bar.1.gz.

It's that last sentence that catches my eye.

My man(1) is
14:33 $ man -h
man, version 1.6g
distributed as part of Slackware 14.2, from the source maintained by
Federico Lucifredi (flucifredi@acm.org).

It appears to explicitly /not/ be part of the man-db package, stating in
it's README that
There is a very different man program, also derived from
John Eaton's original version (by Graeme W. Wilford)
distributed under the name man_db, with version numbers
like man_db-2.3.10. Do not confuse the two, they are
mutually incompatible, although they perform nearly the same job.

--
Lew Pitcher
"In Skills We Trust"

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> On Tue, 16 Jan 2024 11:00:13 -0800, Keith Thompson wrote:
>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>> [...]
>>>> Or, if you want to specify the section (given that some
>>>> sections have man pages with names that you might find
>>>> in other sections):
>>>>
>>>> man section manpage
>>>>
>>>> as in
>>>> man 1 mktemp
>>>> which describes the program "mktemp", vs
>>>> man 3 mktemp
>>>> which describes the library function "mktemp()"
>>>
>>> You can also type
>>> man mktemp.1
>>> or
>>> man mktemp.3
>>
>> That only works if there's a file called "mktemp.1"
>> (or "mktemp.3") in your local directory, at least
>> for the version of man(1) that I have available.
>
>Interesting.
>
>I have man 2.20.1 on Ubuntu, provided by the "man-db" package.

It doesn't work that way on my ancient Fedora 20 install (mandb-2.6.5-6)

It does work that way on my Ubuntu 18 install (man-db-2.8.3)

On Tue, 16 Jan 2024 16:13:36 GMT, Scott Lurndal wrote:

> @$(QUIET) || echo " BUILDPDF $@" $(HUSHCOMPILE)groff -t -man $< | ps2pdf - > $@

Why, can’t your groff installation generate PDF directly?

On Tue, 16 Jan 2024 11:23:52 -0800, Keith Thompson wrote:

> I have man 2.20.1 on Ubuntu, provided by the "man-db" package.
> "man mktemp.1" will look up the corresponding man page in $MANPATH.

It also works if the file is mktemp.1.gz.

> If I want to use a local file, I can use an absolute or relative path
> with a '/' in it, such as "man ./mktemp.1".

Yup. Or the “-l” option.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Tue, 16 Jan 2024 16:13:36 GMT, Scott Lurndal wrote:
>
>> @$(QUIET) || echo " BUILDPDF $@" $(HUSHCOMPILE)groff -t -man $< | ps2pdf - > $@
>
>Why, can’t your groff installation generate PDF directly?

It couldn't when I first wrote this rule a couple of decades ago.

On Tue, 16 Jan 2024 22:55:55 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>Why, can’t your groff installation generate PDF directly?
>
> It couldn't when I first wrote this rule a couple of decades ago.

Here’s how I get a nicely typeset view of one of my own man pages:

groff -ktman -Tpdf «troff-file» | okular - &

On 17/01/2024 07:04, Scott Lurndal wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>> On Tue, 16 Jan 2024 11:00:13 -0800, Keith Thompson wrote:
>>>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>>> [...]
>>>>> Or, if you want to specify the section (given that some
>>>>> sections have man pages with names that you might find
>>>>> in other sections):
>>>>>
>>>>> man section manpage
>>>>>
>>>>> as in
>>>>> man 1 mktemp
>>>>> which describes the program "mktemp", vs
>>>>> man 3 mktemp
>>>>> which describes the library function "mktemp()"
>>>>
>>>> You can also type
>>>> man mktemp.1
>>>> or
>>>> man mktemp.3
>>>
>>> That only works if there's a file called "mktemp.1"
>>> (or "mktemp.3") in your local directory, at least
>>> for the version of man(1) that I have available.
>>
>> Interesting.
>>
>> I have man 2.20.1 on Ubuntu, provided by the "man-db" package.
>
> It doesn't work that way on my ancient Fedora 20 install (mandb-2.6.5-6)
>
> It does work that way on my Ubuntu 18 install (man-db-2.8.3)
>
Hmm, Solaris 11.4, the first few lines of "man man":

NAME
man - find and display reference manual pages

SYNOPSIS
man [-] [-adFlrt] [-M path] [-T macro-package] [-s section] name...

man [-M path] [-s section] -k query...

man [-M path] -f file...

man [-M path] [-s section] -K query...

Still very SysV, but it does use groff now. :-)

For those who want to see the full version:
<https://docs.oracle.com/cd/E88353_01/html/E37839/man-1.html>

Cheers,
Gary B-)

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Tue, 16 Jan 2024 22:55:55 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>>Why, can’t your groff installation generate PDF directly?
>>
>> It couldn't when I first wrote this rule a couple of decades ago.
>
>Here’s how I get a nicely typeset view of one of my own man pages:
>
> groff -ktman -Tpdf «troff-file» | okular - &

$ type okular
-ksh: whence: okular: not found

On Wed, 17 Jan 2024 00:45:54 +0000, Lawrence D'Oliveiro wrote:

> On Tue, 16 Jan 2024 22:55:55 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>>Why, can’t your groff installation generate PDF directly?
>>
>> It couldn't when I first wrote this rule a couple of decades ago.
>
> Here’s how I get a nicely typeset view of one of my own man pages:
>
> groff -ktman -Tpdf «troff-file» | okular - &

man -t 3 mktemp >mktemp.ps

--
Lew Pitcher
"In Skills We Trust"

On Wed, 17 Jan 2024 16:07:54 +0000, Lew Pitcher wrote:

> On Wed, 17 Jan 2024 00:45:54 +0000, Lawrence D'Oliveiro wrote:
>
>> On Tue, 16 Jan 2024 22:55:55 GMT, Scott Lurndal wrote:
>>
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>
>>>>Why, can’t your groff installation generate PDF directly?
>>>
>>> It couldn't when I first wrote this rule a couple of decades ago.
>>
>> Here’s how I get a nicely typeset view of one of my own man pages:
>>
>> groff -ktman -Tpdf «troff-file» | okular - &
>
>
> man -t 3 mktemp >mktemp.ps

But you wanted a PDF, so
man -t 3 mktemp | ps2pdf - mktemp.pdf

--
Lew Pitcher
"In Skills We Trust"

On Wed, 17 Jan 2024 16:03:41 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>>Here’s how I get a nicely typeset view of one of my own man pages:
>>
>> groff -ktman -Tpdf «troff-file» | okular - &
>
> $ type okular
> -ksh: whence: okular: not found

ldo@theon:~> apt-cache search okular
okular-backend-odp - Okular backend for ODP documents
okular-backend-odt - Okular backend for ODT documents
libokular5core11 - libraries for the Okular document viewer
okular - universal document viewer
okular-dev - development files for the Okular libraries
okular-extra-backends - additional document format support for Okular
okular-mobile - mobile support for Okular
qml-module-org-kde-okular - mobile support for Okular - QML modules

It helps to try the right command ...

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 17 Jan 2024 16:03:41 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>>Here’s how I get a nicely typeset view of one of my own man pages:
>>>
>>> groff -ktman -Tpdf «troff-file» | okular - &
>>
>> $ type okular
>> -ksh: whence: okular: not found
>
> ldo@theon:~> apt-cache search okular
> okular-backend-odp - Okular backend for ODP documents
> okular-backend-odt - Okular backend for ODT documents
> libokular5core11 - libraries for the Okular document viewer
> okular - universal document viewer
> okular-dev - development files for the Okular libraries
> okular-extra-backends - additional document format support for Okular
> okular-mobile - mobile support for Okular
> qml-module-org-kde-okular - mobile support for Okular - QML modules
>
>It helps to try the right command ...

My Fedora install doesn't support apt-cache, apt or dpkg commands.

I'm perfectly aware that one can download pretty much any package
for any distribution, however:

xpdf is the best linux pdf viewer, in my opinion. I detest acroread, evince and similar ilk.

On Wed, 17 Jan 2024 22:08:25 GMT, Scott Lurndal wrote:

> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>
>> ldo@theon:~> apt-cache search okular
>> okular-backend-odp - Okular backend for ODP documents
>> okular-backend-odt - Okular backend for ODT documents
>> libokular5core11 - libraries for the Okular document viewer
>> okular - universal document viewer
>> okular-dev - development files for the Okular libraries
>> okular-extra-backends - additional document format support for Okular
>> okular-mobile - mobile support for Okular
>> qml-module-org-kde-okular - mobile support for Okular - QML modules
>
> My Fedora install doesn't support apt-cache, apt or dpkg commands.

Don’t you know what their equivalents are?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Wed, 17 Jan 2024 22:08:25 GMT, Scott Lurndal wrote:
>
>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>
>>> ldo@theon:~> apt-cache search okular
>>> okular-backend-odp - Okular backend for ODP documents
>>> okular-backend-odt - Okular backend for ODT documents
>>> libokular5core11 - libraries for the Okular document viewer
>>> okular - universal document viewer
>>> okular-dev - development files for the Okular libraries
>>> okular-extra-backends - additional document format support for Okular
>>> okular-mobile - mobile support for Okular
>>> qml-module-org-kde-okular - mobile support for Okular - QML modules
>>
>> My Fedora install doesn't support apt-cache, apt or dpkg commands.
>
>Don’t you know what their equivalents are?

Of course. rpm and/or yum. I'm not interested in changing PDF readers, however.

Ah, a google search shows that Okular is like evince and acroread. No thanks.

scott@slp53.sl.home (Scott Lurndal) writes:
> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>On Wed, 17 Jan 2024 22:08:25 GMT, Scott Lurndal wrote:
>>> Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>>>> ldo@theon:~> apt-cache search okular
>>>> okular-backend-odp - Okular backend for ODP documents
>>>> okular-backend-odt - Okular backend for ODT documents
>>>> libokular5core11 - libraries for the Okular document viewer
>>>> okular - universal document viewer
>>>> okular-dev - development files for the Okular libraries
>>>> okular-extra-backends - additional document format support for Okular
>>>> okular-mobile - mobile support for Okular
>>>> qml-module-org-kde-okular - mobile support for Okular - QML modules
>>>
>>> My Fedora install doesn't support apt-cache, apt or dpkg commands.
>>
>>Don’t you know what their equivalents are?
>
> Of course. rpm and/or yum. I'm not interested in changing PDF
> readers, however.

Nobody suggested you should change PDF readers. Lawrence indicted how
he gets a nicely typeset view of one of his own man pages that's all.
You obviously know enough to adapt his method for your own system and
preferences.

--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

On 17.01.2024 23:08, Scott Lurndal wrote:
>
> xpdf is the best linux pdf viewer, in my opinion. I detest acroread,
> evince and similar ilk.

When I call xpdf I get the message "Use evince instead of xpdf!" - not
from the xpdf tool but from a xpdf function I installed. (Not that I'd
particularly like evince, but there obviously had been some deficiency
with xpdf that even evince looked better to me.) So the my question is,
if none of the ones mentioned above, what would a good PDF viewer then
be?

Janis

PS: I just retried xpdf and found the reason for my former aversion...
"Segmentation fault (core dumped)"

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

> On 17.01.2024 23:08, Scott Lurndal wrote:
>>
>> xpdf is the best linux pdf viewer, in my opinion. I detest acroread,
>> evince and similar ilk.
>
> When I call xpdf I get the message "Use evince instead of xpdf!" - not
> from the xpdf tool but from a xpdf function I installed. (Not that I'd
> particularly like evince, but there obviously had been some deficiency
> with xpdf that even evince looked better to me.) So the my question is,
> if none of the ones mentioned above, what would a good PDF viewer then
> be?

On Windows, there's nothing better than Sumatra PDF

https://www.sumatrapdfreader.org/

I confirm all the testimonials. The problem with Sumatra PDF is finding
a way to pronounce the name of the author, Krzysztof Kowalczyk, not to
mention spelling it.

In article <uodkv0$33q7m$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
....
>PS: I just retried xpdf and found the reason for my former aversion...
>"Segmentation fault (core dumped)"

I assume this is just on one particular PDF file of yours, since obviously
xpdf works on other files. It has always worked for me.

Or, your installation of xpdf is broken...

--
After Using Gender Slur Against AOC, GOP Rep. Yoyo Won't Apologize 'For Loving God'.

That's so sweet...