On 31.01.2024 15:09, David Brown wrote:
>
> I would expect that the majority of uses of "cat" are with just one
> file,

And of course just because of ignorance; the majority of (but not all)
uses with just one file are UUOCs.

> but certainly it is useful when you want to combine files in
> different ways.

I don't know of any concatenations in "different" ways, but of course
there's some more of the other usages that are supported by options.

Janis

On Wed, 31 Jan 2024 12:15:23 +0000
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:

> On 31/01/2024 10:43, Michael S wrote:
> > On Tue, 30 Jan 2024 23:18:21 -0800
> > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
> >
> >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>
> >>> On 30/01/2024 07:27, Tim Rentsch wrote:
> >>>
> >>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>>>
> >>>>> On 29/01/2024 20:10, Tim Rentsch wrote:
> >>>>>
> >>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> >>>>>>
> >>>>>> [...]
> >>>>>>
> >>>>>>> I've never used standard output for binary data.
> >>>>>>> [...] it strikes me as a poor design decision.
> >>>>>>
> >>>>>> How so?
> >>>>>
> >>>>> Because the output can't be inspected by humans, and because it
> >>>>> might have unusual effects if passed though systems designed to
> >>>>> handle human-readable text. For instance in some systems
> >>>>> designed to receive ASCII text, there is no distinction between
> >>>>> the nul byte and "waiting for next data byte". Obviously this
> >>>>> will cause difficuties if the data is binary.
> >>>>> Also many binary formats can't easily be extended, so you can
> >>>>> pass one image and that's all. While it is possible to devise a
> >>>>> text format which is similar, in practice text formats usually
> >>>>> have enough redundancy to be easily extended.
> >>>>>
> >>>>> So it's harder to correct errors, more prone to errors, and
> >>>>> harder to extend.
> >>>>
> >>>> Your reasoning is all gobbledygook. Your comments reflect only
> >>>> limitations in your thinking, not any essential truth about using
> >>>> standard out for binary data.
> >>>
> >>> I must admit that it's nothing I have ever done or considered
> >>> doing.
> >>>
> >>> [...]
> >>
> >> Simple example (disclaimer: not tested):
> >>
> >> ssh foo 'cd blah ; tar -cf - . | gzip -c' | \
> >> (mkdir foo.blah ; cd foo.blah ; gunzip -c | tar -xf -)
> >>
> >> Of the five main programs in this command, four are using
> >> standard out to send binary data:
> >>
> >> tar -cf - .
> >> gzip -c
> >> ssh foo [...]
> >> gunzip -c
> >>
> >> The tar -xf - at the end reads binary data on standard in
> >> but doesn't output any (or anything else for that matter).
> >>
> >> It is FAR more cumbersome to accomplish what this command
> >> is doing without sending binary data through standard out.
> >
> > If I am not mistaken, tar, gzip and gunzip do not write binary data
> > to standard output by default. They should be specifically told to
> > do so. For ssh I don't know. Anyway, ssh is not a "normal" program
> > so it's not surprising when textuality of ssh output is the same as
> > textuality of the command it carries.
> >
> >> Anyone who doesn't understand this doesn't understand Unix.
> >
> > Frankly, Unix redirection racket looks like something hacked
> > together rather than designed as result of the solid thinking
> > process. As long as there were only standard input and output it
> > was sort of logical. But when they figured out that it is
> > insufficient, they had chosen a quick hack instead of constructing
> > a solution that wouldn't offend engineering senses of any
> > non-preconditioned observer.
> It was designed for very memory constrained systems which handled
> text on a line by line basis. So one line of a long file wuld be
> processed and passed down the pipeline, and you wouldn't need
> temporary disk files or large amounts of memory. I'm sure it worked
> quite well for that.
>
>

A concept of pipes is fine. I was not talking about that side.

My objection is with each program having exactly 1 special input and
exactly 2 special outputs. Instead of having, say, up to 5 of each,
fully interchangeable with the first of the five being special only in
that that it is a default and as such allows for shorter syntax in the
shell.

I would be surprised if something like that was not done by somebody.
I would be even more surprised if idea did not cross the mind of Unix
pioneers. However they decided to add stderr and to stop here. Most
likely, because they didn't take themselves as seriously as few posters
here take them 45-50 years later.

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Tue, 30 Jan 2024 17:49:57 +0100, David Brown wrote:
>
>> The use of CRLF as a standard for line endings in files was, I believe,
>> from CP/M ...
>
>Which I think copied it from DEC minicomputer systems.
>
>Fun fact: on some of those DEC systems (which I used when they were still
>being made), you could end a line with CR-LF, or LF-CR-NUL.
>
>What was the NUL for? Padding. Why did it need padding? (This was before
>CRT terminals.)

Unix built the nul-padding into the terminal driver. Users used
the stty command to set the number of nul's (based on the time it
took for the ASR33 carriage to return to the home position after
it recieved a CR).

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Tue, 30 Jan 2024 11:50:35 -0800, Keith Thompson wrote:
>
>> VMS (now OpenVMS) was also a significant system at the time, and it had
>> some rather complex file formats ...
>
>It relied on extra file metadata called “record attributes” in order to
>make sense of the file format. It was quite common to transfer files from
>other systems, and have them not be readable until you had set appropriate
>record attributes on them. Picky, picky, I know.

At my first job, I had to write a tool (in macro32) to support access
to any type of file, regardless of the RMS attributes. Wasn't a trivial
task like it would have been on a unix system.

VMS inherited that from the mainframe systems whose filesystem were
based around COBOL file handling.

At least it was far superior to IBM's PDS and associated crap.

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>On 31.01.2024 12:58, Michael S wrote:
>> On Wed, 31 Jan 2024 12:43:04 +0100
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>
>>> On 31.01.2024 07:02, Lawrence D'Oliveiro wrote:
>>>> On Tue, 30 Jan 2024 11:50:35 -0800, Keith Thompson wrote:
>>>>
>>>>> VMS (now OpenVMS) was also a significant system at the time, and
>>>>> it had some rather complex file formats ...
>>>>
>>>> [...]
>>>>
>>>> Apparently Linus Torvalds used VMS for a while, and hated it.
>>>
>>> I don't understand the intention of this comment.
>>> VMS and Torvalds are completely different eras.
>>> And were is the relation?
>>>
>>
>> Linus is older than you probably realize.
>
>Why do you think that I'd be thinking that?
>
>I know that he's quite some years younger than I am. So what?
>
>> He entered the University of
>> Helsinki in 1988. Back then VMS was only slightly behind its peak of
>> popularity.
>
>What? - I'm not sure where you're coming from.
>
>I associate DEC's VMS with the old DEC VAX-11 system, both
>from around the mid of the 1970's.

Early customer systems were shipped around 1979, IIRC. We had four.

David Brown <david.brown@hesbynett.no> writes:
>On 31/01/2024 07:07, Lawrence D'Oliveiro wrote:
>> On Tue, 30 Jan 2024 17:25:31 +0100, David Brown wrote:
>>
>>> Mixing binary data with formatted text data is very unlikely to be
>>> useful.
>>
>> PDF does exactly that. To the point where the spec suggests putting some
>> random unprintable bytes up front, to distract format sniffers from
>> thinking they’re looking at a text file.
>
>PDF files start with the "magic" indicator "%PDF", which is enough for
>many programs to identify them correctly. And they are usually
>compressed so that the content text is not directly readable or
>identifiable as strings. If they are not compressed, then yes, there is
>can be text mixed in with everything else. But I would not call that
>"mixing binary data and formatted text" - I would just say that some of
>the binary data happens to be strings. It's the same as elf files
>containing copies of strings from the program, or identifiers for
>external linking.
>
>However, I learned a new trick when checking that I was not mistaken
>about this - it turns out that "less file.pdf" gives a nice text-only
>output from the pdf file (by passing it through "lesspipe"). There's
>always something new to learn from inane conversations on Usenet :-)

For many years, I used a tool called 'antiword' to read legacy microsoft
windows .doc files (before .docx).

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>On Tue, 30 Jan 2024 19:39:24 +0000, Richard Harnden wrote:
>
>> Nobody uses printf to output binary data.
>
>Do terminal-control escape sequences count?

Or UTF-*?

David Brown <david.brown@hesbynett.no> writes:
>On 31/01/2024 09:36, Malcolm McLean wrote:

>> The reason is that I'd only run the command once, and it's so likely
>> that there will be either a syntax misunderstanding or a typing error
>> that I'd have to test to ensure that it was right. And by the time
>> you've done that any time saved by typing only one commandline is lost.
>> Of course if you are writing scripts then that doesn't apply. But now
>> it's effectively a programming language, and, from the example code, a
>> very poorly designed one which is cryptic and fussy and liable to be
>> hard to maintain. So it's better to use a language like Perl to achieve
>> the same thing, and I did have a few Perl scripts handy for repetitive
>> jobs of that nature in my Unix days.
>>
>
>That gave me a laugh! You think bash is cryptic, fussy and poorly
>designed, and choose /Perl/ as the alternative :-)
>
>> You admit this with "not tested". Says it all. '"Understandig Unix" is
>> an intellectually useless achievement. You might have to do it if you
>> have to use the system and debug and trouble shoot. But it's nothing to
>> be proud about.
>>
>
>It is "useless" for people who don't use it. For people who /do/ use
>it, is very useful.
>
>I've used sequences like Tim's - it's a way to copy data remotely from a
>different machine. I would likely write it slightly differently - I'd
>probably do the mkdir and cd first, thus avoiding the need for a
>subshell, and I'd use "ssh -C" or "tar -z" to do the compression rather
>than "gzip".
>
>There's no doubt that the learning curve is longer for doing this sort
>of thing from the command line than using gui programs. There is also
>no doubt that when you are used to it, command line utilities and a good
>shell are very flexible and efficient.
>
>Learn to use the tools that are conveniently available, and then pick
>the right tool for the job - whether it is command line or gui.

And there are often more than one tool for the job. e.g. rsync(1)
for copying data remotely.

Michael S <already5chosen@yahoo.com> writes:
>On Tue, 30 Jan 2024 23:18:21 -0800
>Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

>
>> Anyone who doesn't understand this doesn't understand Unix.
>
>Frankly, Unix redirection racket looks like something hacked together
>rather than designed as result of the solid thinking process.

It seems you don't understand Unix.

>As long as there were only standard input and output it was sort of
>logical. But when they figured out that it is insufficient, they had
>chosen a quick hack instead of constructing a solution that wouldn't
>offend engineering senses of any non-preconditioned observer.

You mean like

exec 3< /path/to/input/file
read -u3 line_from_input file

How does that offend your engineering senses?

On 31.01.2024 15:21, David Brown wrote:
> On 31/01/2024 09:36, Malcolm McLean wrote:
>> [ I snipped a couple of "I actually don't know/need it" things ]
>>
>> But now it's effectively a programming language, and, from the example
>> code, a very poorly designed one which is cryptic and fussy and liable
>> to be hard to maintain. So it's better to use a language like Perl to
>> achieve the same thing, and I did have a few Perl scripts handy for
>> repetitive jobs of that nature in my Unix days.
>
> That gave me a laugh! You think bash is cryptic, fussy and poorly
> designed, and choose /Perl/ as the alternative :-)

I don't think it's that clear a joke. The Unix shell is extremely
error prone to program, and you should not let a newbie write shell
programs without careful supervision. ("newbie" [in shell context]
= less than 10 years of practical experience. - Am I exaggerating?
Maybe. But not much.)

And yes, Shell is cryptic, but, OTOH, it's also a programming
language with powerful concepts (taken from Algol68). It wouldn't
appear to me, though, to classify Perl as non-cryptic. You can
write more or less legible shell code; also depends on experience.
You have functions to structure your code, the control constructs,
error handling, the I/O glue, all smoothly fitting together. But,
to be honest, I say this with modern shells in mind (ksh, bash,
zsh), not so much the POSIX subset, and even less the Bourne sh.

Perl's advantage is probably that you have the same interface on
all platforms [where it is installed]. Not having to distinguish,
say, the 'ps' options from one Unix system to another. And it has
a lot more features, data types, and supporting external modules.

>
> There's no doubt that the learning curve is longer for doing this sort
> of thing from the command line than using gui programs. There is also
> no doubt that when you are used to it, command line utilities and a good
> shell are very flexible and efficient.

The big advantage of non-GUI is for process automation. With GUI
oriented applications you can mainly only interactively (=slow and
cumbersome) do what it provides. Rarely GUI applications support a
scripting interface, and if so it's then typically some proprietary
non-standard language.

>
> Learn to use the tools that are conveniently available, and then pick
> the right tool for the job - whether it is command line or gui.

The Unix shell is at least standard and available on Unix systems.
(Perl is no standard on Unix. And you may not be allowed to install
it.)

Janis

David Brown <david.brown@hesbynett.no> writes:
>On 30/01/2024 22:16, James Kuyper wrote:
>> On 1/30/24 11:49, David Brown wrote:
>> ...
>>> If the program can reasonably be expected to generate binary output,
>>> then it is the user's fault if they do this accidentally. Examples
>>> shown in this thread include cat and zcat - that's what these programs do.
>>
>> ? There's no problem using cat to concatenate binary files. I've used
>> 'split' to split binary files into smaller pieces, and then used 'cat'
>> to recombine them, and it worked fine. I don't remember why, but I had
>> to transfer the files from one place to another by a method that imposed
>> an upper limit on the size of individual files.
>>
>
>I think there's a misunderstanding here - I gave "cat" is an example of
>a program that /can/ be expected to produce binary output. (It can also
>produce text output - you get what you put in.) So it is the user's
>fault if the type "cat /bin/cat" and are surprised by a mess in their
>terminal.

Quick and dirty editor:

$ cat > /tmp/file < /dev/tty
line1
line2
line3
^D
$ $ cat /tmp/file
line1
line2
line3
$

On 31.01.2024 16:25, Scott Lurndal wrote:
> Michael S <already5chosen@yahoo.com> writes:
>> [...]
>
> You mean like
>
> exec 3< /path/to/input/file
> read -u3 line_from_input file

Careful with non-standard extensions like '-u'.

>
> How does that offend your engineering senses?

It probably would if the standard redirection pattern
would have been used here. It's certainly more "cryptic"
than '-u3'. ;-)

Janis

On Wed, 31 Jan 2024 15:25:00 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> Michael S <already5chosen@yahoo.com> writes:
> >On Tue, 30 Jan 2024 23:18:21 -0800
> >Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
> >
> >> Anyone who doesn't understand this doesn't understand Unix.
> >
> >Frankly, Unix redirection racket looks like something hacked together
> >rather than designed as result of the solid thinking process.
>
> It seems you don't understand Unix.
>

That's likely.
I learned it during short course ~30 years ago, then read 2 or 3
books about it and then used it quite sporadically.

> >As long as there were only standard input and output it was sort of
> >logical. But when they figured out that it is insufficient, they had
> >chosen a quick hack instead of constructing a solution that wouldn't
> >offend engineering senses of any non-preconditioned observer.
>
> You mean like
>
> exec 3< /path/to/input/file
> read -u3 line_from_input file
>
> How does that offend your engineering senses?
>

That was not in 2-3 books that I had read. I can't say that I understand
what is going on, what environment we are and whether what you show is
generic or specific to 'exec' and 'read'.

Michael S <already5chosen@yahoo.com> writes:
>On Wed, 31 Jan 2024 12:15:23 +0000
>Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:

>> It was designed for very memory constrained systems which handled
>> text on a line by line basis. So one line of a long file wuld be
>> processed and passed down the pipeline, and you wouldn't need
>> temporary disk files or large amounts of memory. I'm sure it worked
>> quite well for that.
>>
>>
>
>A concept of pipes is fine. I was not talking about that side.
>
>My objection is with each program having exactly 1 special input and
>exactly 2 special outputs. Instead of having, say, up to 5 of each,
>fully interchangeable with the first of the five being special only in
>that that it is a default and as such allows for shorter syntax in the
>shell.

Each program has 1024 (on my system - it's configurable on a per-process
basis) fully interchangable "inputs" and "outputs" (also known as files).

$ application 5> /tmp/file5

will redirect file descriptor five to the specified file.

There's nothing special about stdin, stdout or stderr other than
that they are tags applied to the first three file descriptors.

There is a convention the that the first file descriptor
is used for input, the second for output and the third
for diagnostic output. But it's just a convention

On 31/01/2024 15:03, Michael S wrote:
> On Wed, 31 Jan 2024 12:15:23 +0000
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>
>> On 31/01/2024 10:43, Michael S wrote:
>>> On Tue, 30 Jan 2024 23:18:21 -0800
>>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>>>
>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>
>>>>> On 30/01/2024 07:27, Tim Rentsch wrote:
>>>>>
>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>
>>>>>>> On 29/01/2024 20:10, Tim Rentsch wrote:
>>>>>>>
>>>>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>>>>>>>>
>>>>>>>> [...]
>>>>>>>>
>>>>>>>>> I've never used standard output for binary data.
>>>>>>>>> [...] it strikes me as a poor design decision.
>>>>>>>>
>>>>>>>> How so?
>>>>>>>
>>>>>>> Because the output can't be inspected by humans, and because it
>>>>>>> might have unusual effects if passed though systems designed to
>>>>>>> handle human-readable text. For instance in some systems
>>>>>>> designed to receive ASCII text, there is no distinction between
>>>>>>> the nul byte and "waiting for next data byte". Obviously this
>>>>>>> will cause difficuties if the data is binary.
>>>>>>> Also many binary formats can't easily be extended, so you can
>>>>>>> pass one image and that's all. While it is possible to devise a
>>>>>>> text format which is similar, in practice text formats usually
>>>>>>> have enough redundancy to be easily extended.
>>>>>>>
>>>>>>> So it's harder to correct errors, more prone to errors, and
>>>>>>> harder to extend.
>>>>>>
>>>>>> Your reasoning is all gobbledygook. Your comments reflect only
>>>>>> limitations in your thinking, not any essential truth about using
>>>>>> standard out for binary data.
>>>>>
>>>>> I must admit that it's nothing I have ever done or considered
>>>>> doing.
>>>>>
>>>>> [...]
>>>>
>>>> Simple example (disclaimer: not tested):
>>>>
>>>> ssh foo 'cd blah ; tar -cf - . | gzip -c' | \
>>>> (mkdir foo.blah ; cd foo.blah ; gunzip -c | tar -xf -)
>>>>
>>>> Of the five main programs in this command, four are using
>>>> standard out to send binary data:
>>>>
>>>> tar -cf - .
>>>> gzip -c
>>>> ssh foo [...]
>>>> gunzip -c
>>>>
>>>> The tar -xf - at the end reads binary data on standard in
>>>> but doesn't output any (or anything else for that matter).
>>>>
>>>> It is FAR more cumbersome to accomplish what this command
>>>> is doing without sending binary data through standard out.
>>>
>>> If I am not mistaken, tar, gzip and gunzip do not write binary data
>>> to standard output by default. They should be specifically told to
>>> do so. For ssh I don't know. Anyway, ssh is not a "normal" program
>>> so it's not surprising when textuality of ssh output is the same as
>>> textuality of the command it carries.
>>>
>>>> Anyone who doesn't understand this doesn't understand Unix.
>>>
>>> Frankly, Unix redirection racket looks like something hacked
>>> together rather than designed as result of the solid thinking
>>> process. As long as there were only standard input and output it
>>> was sort of logical. But when they figured out that it is
>>> insufficient, they had chosen a quick hack instead of constructing
>>> a solution that wouldn't offend engineering senses of any
>>> non-preconditioned observer.
>> It was designed for very memory constrained systems which handled
>> text on a line by line basis. So one line of a long file wuld be
>> processed and passed down the pipeline, and you wouldn't need
>> temporary disk files or large amounts of memory. I'm sure it worked
>> quite well for that.
>>
>>
>
> A concept of pipes is fine. I was not talking about that side.
>
> My objection is with each program having exactly 1 special input and
> exactly 2 special outputs. Instead of having, say, up to 5 of each,
> fully interchangeable with the first of the five being special only in
> that that it is a default and as such allows for shorter syntax in the
> shell.
>
> I would be surprised if something like that was not done by somebody.
> I would be even more surprised if idea did not cross the mind of Unix
> pioneers. However they decided to add stderr and to stop here. Most
> likely, because they didn't take themselves as seriously as few posters
> here take them 45-50 years later.
>
>
The BabyX resource compiler taes images, fonts, etc and outputs C
source. So it writes the source to standard outout to make it a bit
easier for scripts to integrate it. Whether anyone has actually done
that I don't know - always just redirect the iutout to a pipe and so
there's nor real advantage over using a filename.

However I recently modified the program to also output an associated
header. Now the ASCII way to do that is to send an ETX to separate the
outputs. That's never going work in an integration. So in fact I write
to a .h file which I open internally. And so there's now very little
point in having the main .c resuts on stnadard output.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

Michael S <already5chosen@yahoo.com> writes:
>On Wed, 31 Jan 2024 15:25:00 GMT
>scott@slp53.sl.home (Scott Lurndal) wrote:

>> You mean like
>>
>> exec 3< /path/to/input/file
>> read -u3 line_from_input file
>>
>> How does that offend your engineering senses?
>>
>
>That was not in 2-3 books that I had read. I can't say that I understand
>what is going on, what environment we are and whether what you show is
>generic or specific to 'exec' and 'read'.

It is acutally specific to a shell which provides internal
'exec' and 'read' commands. There are dozens of shells available
to suit the end-users requirements (bourne shell, korn shell, C shell
et alia), many of them implement a common subset of commands
defined by POSIX.

From the unix kernel perspective, an application opens a file and a file
descriptor is assigned (consecutively, starting at zero). There
are no semantics associated with the fd which can refer to a terminal,
pseudo-terminal, block device, character device, pipe,
named fifo, or even a TCP connection to a remote host.

Any semantics associated with the file descriptor are a contract
between the shell and the application.

One could certainly write a shell that doesn't use file descriptor
zero as stdin (although that would be incompatable with applications
written for the standard shells, all of which honor the convention
that file descriptor zero is stdin).

For portability between shells, POSIX has codified the relationship
of stdin to fd 0, stdout to fd1, etc.

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>On 31.01.2024 15:21, David Brown wrote:
>> On 31/01/2024 09:36, Malcolm McLean wrote:
>>> [ I snipped a couple of "I actually don't know/need it" things ]
>>>
>>> But now it's effectively a programming language, and, from the example
>>> code, a very poorly designed one which is cryptic and fussy and liable
>>> to be hard to maintain. So it's better to use a language like Perl to
>>> achieve the same thing, and I did have a few Perl scripts handy for
>>> repetitive jobs of that nature in my Unix days.
>>
>> That gave me a laugh! You think bash is cryptic, fussy and poorly
>> designed, and choose /Perl/ as the alternative :-)
>
>I don't think it's that clear a joke. The Unix shell is extremely
>error prone to program, and you should not let a newbie write shell
>programs without careful supervision.

Nonsense.

On 31/01/2024 14:21, David Brown wrote:
> On 31/01/2024 09:36, Malcolm McLean wrote:
>>
>
> That gave me a laugh!  You think bash is cryptic, fussy and poorly
> designed, and choose /Perl/ as the alternative :-)
>

I'm not a great fan of Perl and if I was writing the language then it
would look a lot different to what it does now. But I wasn't the person
to implement it and, for various reasons, you have to use what is
standard (when I had the Unix system some other people in the lab were
doing their main work in Perl, because it had good bioinformatics
libraries, so of course that Perl a natural choice for little scripts
which otherwise would have been written in a shell language).

However the main advantage of Perl is that it was designed from the
start as a programming language in which programmers would write
human-readable, maintainable scripts. And you can write it reasonably
clearly with care, if you avoid some of the more idiomatic features.

--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm

On Wed, 31 Jan 2024 15:49:10 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:

> Michael S <already5chosen@yahoo.com> writes:
> >On Wed, 31 Jan 2024 12:15:23 +0000
> >Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:
>
> >> It was designed for very memory constrained systems which handled
> >> text on a line by line basis. So one line of a long file wuld be
> >> processed and passed down the pipeline, and you wouldn't need
> >> temporary disk files or large amounts of memory. I'm sure it worked
> >> quite well for that.
> >>
> >>
> >
> >A concept of pipes is fine. I was not talking about that side.
> >
> >My objection is with each program having exactly 1 special input and
> >exactly 2 special outputs. Instead of having, say, up to 5 of each,
> >fully interchangeable with the first of the five being special only
> >in that that it is a default and as such allows for shorter syntax
> >in the shell.
>
> Each program has 1024 (on my system - it's configurable on a
> per-process basis) fully interchangable "inputs" and "outputs" (also
> known as files).
>
> $ application 5> /tmp/file5
>
> will redirect file descriptor five to the specified file.
>
>
> There's nothing special about stdin, stdout or stderr other than
> that they are tags applied to the first three file descriptors.
>
> There is a convention the that the first file descriptor
> is used for input, the second for output and the third
> for diagnostic output. But it's just a convention

I don't understand.
Are not descriptors 0,1 and 2 special in that that they are already
open (I don't know if by OS or by shell) when the program starts and the
rest of them, if ever used, have to be opened by the program code?

On only remotely related note, what happens on your system when you
want more than 1024 files to be open by one program simultaneously?

On 31.01.2024 16:42, Michael S wrote:
> On Wed, 31 Jan 2024 15:25:00 GMT
> scott@slp53.sl.home (Scott Lurndal) wrote:
>>
>> You mean like
>>
>> exec 3< /path/to/input/file
>> read -u3 line_from_input file
>>
>> How does that offend your engineering senses?
>
> That was not in 2-3 books that I had read. I can't say that I understand
> what is going on, what environment we are and whether what you show is
> generic or specific to 'exec' and 'read'.

'-u' is obviously an option of read. Various shells support it; at least
ksh since 30 years, and bash meanwhile as well. But it's not in POSIX.

Other redirections are standard, and these should certainly be known by
anyone who had visited a course and read any book on the Unix shell.
The syntax is not difficult, follows rules, and certainly not arbitrary.

The one in above code is assigning the file descriptor 3 to the given
file for reading. You can let a FD point to the channel another one is
pointing to, like in the "well known" '2>&1' (where stderr is connected
to the same channel than stdin currently points to). Similar you can in
above example use the standard form 'read line_from_input_file <&3',
which may certainly appear more cryptic than an option '-u3', but it's
essential to any shell programmer.

Janis

On 31.01.2024 16:58, Scott Lurndal wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 31.01.2024 15:21, David Brown wrote:
>>> On 31/01/2024 09:36, Malcolm McLean wrote:
>>>> [ I snipped a couple of "I actually don't know/need it" things ]
>>>>
>>>> But now it's effectively a programming language, and, from the example
>>>> code, a very poorly designed one which is cryptic and fussy and liable
>>>> to be hard to maintain. So it's better to use a language like Perl to
>>>> achieve the same thing, and I did have a few Perl scripts handy for
>>>> repetitive jobs of that nature in my Unix days.
>>>
>>> That gave me a laugh! You think bash is cryptic, fussy and poorly
>>> designed, and choose /Perl/ as the alternative :-)
>>
>> I don't think it's that clear a joke. The Unix shell is extremely
>> error prone to program, and you should not let a newbie write shell
>> programs without careful supervision.
>
> Nonsense.

Not the least. - I'm not sure about your background in shell. But all
what you wrote in this newsgroup is indicating that your experience
seems to be quite limited. (I've seen only a single and pointless post
from you in comp.unix.shell). - Nevermind. Just don't expose yourself
so much with your obviously little knowledge and experience.

Janis

On Wed, 31 Jan 2024 17:05:23 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> On 31.01.2024 16:42, Michael S wrote:
> > On Wed, 31 Jan 2024 15:25:00 GMT
> > scott@slp53.sl.home (Scott Lurndal) wrote:
> >>
> >> You mean like
> >>
> >> exec 3< /path/to/input/file
> >> read -u3 line_from_input file
> >>
> >> How does that offend your engineering senses?
> >
> > That was not in 2-3 books that I had read. I can't say that I
> > understand what is going on, what environment we are and whether
> > what you show is generic or specific to 'exec' and 'read'.
>
> '-u' is obviously an option of read. Various shells support it; at
> least ksh since 30 years, and bash meanwhile as well. But it's not in
> POSIX.
>

The books were talking about Bourne shell and C shell. They acknowledged
an existence of ksh, but didn't go into details. I don't remember if
bash was mentioned at all.
Of course, in practice in this century I used bash almost exclusively,
but never learned it formally, by book, from start to finish.
The same as over 90% of bash users, I'd guess.

> Other redirections are standard, and these should certainly be known
> by anyone who had visited a course and read any book on the Unix
> shell. The syntax is not difficult, follows rules, and certainly not
> arbitrary.
>
> The one in above code is assigning the file descriptor 3 to the given
> file for reading. You can let a FD point to the channel another one is
> pointing to, like in the "well known" '2>&1' (where stderr is
> connected to the same channel than stdin currently points to).
> Similar you can in above example use the standard form 'read
> line_from_input_file <&3', which may certainly appear more cryptic
> than an option '-u3', but it's essential to any shell programmer.
>
> Janis
>

I did understand '3<' by association with '2>' that was in the book,
but more importantly, is something I use regularly.
However I had never seen '3<' in the books.

On 1/31/24 07:35, Janis Papanagnou wrote:
....
> I associate DEC's VMS with the old DEC VAX-11 system, both
> from around the mid of the 1970's. I programmed on a DEC's
> VAX with VMS obviously before Linus Torvalds started his
> studies. And that was at a time when the DEC VAX and VMS
> were replaced at our sites by Unix systems.

OK - so it's that association you've got wrong. I know VMS was still
going strong around 1990 when I was introduced to it. It might have been
in decline at the time, but it was very far from being gone.

On Wed, 31 Jan 2024 16:25:30 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

>
> The big advantage of non-GUI is for process automation. With GUI
> oriented applications you can mainly only interactively (=slow and
> cumbersome) do what it provides. Rarely GUI applications support a
> scripting interface, and if so it's then typically some proprietary
> non-standard language.
>

I'd take almost any proprietary non-standard GUI macro language over
non-proprietary non-standard tcl. They say, Lua is better. I never had
motivation to look at it more closely.

On Wed, 31 Jan 2024 18:26:36 +0200
Michael S <already5chosen@yahoo.com> wrote:

> On Wed, 31 Jan 2024 16:25:30 +0100
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>
> >
> > The big advantage of non-GUI is for process automation. With GUI
> > oriented applications you can mainly only interactively (=slow and
> > cumbersome) do what it provides. Rarely GUI applications support a
> > scripting interface, and if so it's then typically some proprietary
> > non-standard language.
> >
>
> I'd take almost any proprietary non-standard GUI macro language over
> non-proprietary non-standard tcl. They say, Lua is better. I never had
> motivation to look at it more closely.
>

meant to write 'non-proprietary standard tcl'