On 31.01.2024 16:03, Michael S wrote:
>
> 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.

The first three are pre-assigned and read to use for application.
You can redirect, close, or open them on shell level with a set of
redirection commands, and you can do such things also on OS-level
with the Unix system commands.

I'm not sure why you mentioned 5, whether that's better or worse.
There's naturally some limit on OS level on the number of parallel
open file descriptors, but that limit is very high. Mind that you
can always close unused ones.

Janis

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> 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.

OpenVMS V9.2-2 was released this month. V9.2-1 is supported until
December 2026.

[...]

--
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 */

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
> On 31/01/2024 07:18, Tim Rentsch wrote:
[...]
>> It is FAR more cumbersome to accomplish what this command
>> is doing without sending binary data through standard out.
>> Anyone who doesn't understand this doesn't understand Unix.
>>
> Yes. I don't do that sort of thing.

You don't. Others do. What was your point again?

[...]

--
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 */

David Brown <david.brown@hesbynett.no> writes:
[...]
> 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 :-)

It doesn't necessarily do this by default. See the documentation for
details (which are of course off-topic here).

--
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 */

scott@slp53.sl.home (Scott Lurndal) writes:
[...]
> Quick and dirty editor:
>
> $ cat > /tmp/file < /dev/tty
> line1
> line2
> line3
> ^D
> $
> $ cat /tmp/file
> line1
> line2
> line3
> $

You probably don't need the "< /dev/tty".

--
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 31.01.2024 17:18, Michael S wrote:
> On Wed, 31 Jan 2024 17:05:23 +0100
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>
> 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.

So that's understandable then. The C shell is not really suited for
programming (and commonly depreciated; "C shell considered harmful").
And Bourne sh is indeed very restricted.

> Of course, in practice in this century I used bash almost exclusively,
> but never learned it formally, by book, from start to finish.

In case that bash is still part of your working environment I suggest
to update your knowledge by reading some good bash tutorial. It's
really a huge gain if compared to Bourne sh. In case, though, you want
to do _portable_ shell programming then take some book that clearly
indicates what is POSIX and what is some extension.

> The same as over 90% of bash users, I'd guess.

Well, I think you have to differentiate the levels. Quite many users
of bash take this shell as "quasi-standard"; which is mostly okay in a
Linux world. And know exactly that universe. If you happen to work in
a larger Unix universe that might be a hindrance. (Thus POSIX, or use
of ksh, which is even more powerful than bash, or zsh, supplemented
with its own but some more coherent concepts.)

>
> 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.

It's just the numbers of file descriptors and whether it's an input >
or output < channel, or even a read/write channel <> . That's why in
books (or man pages) you regularly see the building blocks, not the
complete enumeration.

(See for example 'man ksh' Section "Input/Output". But careful; ksh
has additional non-standard additions. So a peek into the POSIX docs
might serve you better.)

Janis

Michael S <already5chosen@yahoo.com> writes:
>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?

That's a contract between a shell and an application. A shell
doesn't need to provide POSIX semantics, although it will likely
do so just to maintain compataiblity with existing applications.

Applications like daemons usually are disconnected from stdin/stdout/stderr
completely, as they're not designed for interactive use.

Using the fork and exec (or posix_spawn) system calls, an application can invoke another
application without the shell and any number of file descriptors
can be left open for the child to use in any way. It's a contract
between the two applications.

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

$ ulimit -f 2048

Will increase the limit, to any arbitrary value, subject to system
wide limits configured by the superuser (system manager).

There's a system call (setrlimit) that an application can use as well, and the
limit will be inherited by child processes.

One might argue that there are few cases (absent network daemons)
where more than 2k files will need to be open simultaneously.

For each resource (address space size, core file size, max cpu time,
file size, open files, et cetera, et alia) there are two values;
a hard limit (which a process can never exceed) and a soft limit.
A process can increase the soft limit up to the hard limit.

In my case, the hard limit is 8192 and the soft limit is 1024.

$ ulimit -aH
address space limit (Kibytes) (-M) unlimited
core file size (blocks) (-c) unlimited
cpu time (seconds) (-t) unlimited
data size (Kibytes) (-d) unlimited
file size (blocks) (-f) unlimited
locks (-x) unlimited
locked address space (Kibytes) (-l) 64
message queue size (Kibytes) (-q) 800
nice (-e) 0
nofile (-n) 8192
nproc (-u) 63878
pipe buffer size (bytes) (-p) 4096
max memory size (Kibytes) (-m) unlimited
rtprio (-r) 0
socket buffer size (bytes) (-b) 4096
sigpend (-i) 63878
stack size (Kibytes) (-s) unlimited
swap size (Kibytes) (-w) not supported
threads (-T) not supported
process size (Kibytes) (-v) unlimited
$ ulimit -aS
address space limit (Kibytes) (-M) unlimited
core file size (blocks) (-c) 0
cpu time (seconds) (-t) unlimited
data size (Kibytes) (-d) unlimited
file size (blocks) (-f) unlimited
locks (-x) unlimited
locked address space (Kibytes) (-l) 64
message queue size (Kibytes) (-q) 800
nice (-e) 0
nofile (-n) 1024
nproc (-u) 1024
pipe buffer size (bytes) (-p) 4096
max memory size (Kibytes) (-m) unlimited
rtprio (-r) 0
socket buffer size (bytes) (-b) 4096
sigpend (-i) 63878
stack size (Kibytes) (-s) 8192
swap size (Kibytes) (-w) not supported
threads (-T) not supported
process size (Kibytes) (-v) unlimited

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>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.

I've been using shells (sh, ksh) daily since 1979. I've contributed code
to the linux kernel (a kernel debugger called kdb in 1998).
I've contributed code to Oracle's RDBMS (OS dependent I/O code).
I've co-written a unix-compatible distributed operating system[*] for a massively
parallel machine (in C++) and two bare-metal hypervisors which execute
linux guest operating systems. I spent 6 years on the base working group
at X/Open and the Open Group working on the XPG standards (which were merged
with the POSIX standards a decade ago).

I won't say that there aren't gotchas when writing shell scripts,
particularly when used by someone with elevated privileged, but that
doesn't make them "extremely error prone".

[*] eventually in partnership with USL (Unix System Labs - i.e. AT&T), Fujitsu, ICL.

On 31.01.2024 17:20, James Kuyper wrote:
> 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.

I am aware that it was also existing in the late 1990's, if
at least through the openVMS form. I certainly have not the
whole market in view. All I can say is what I wrote, that we
have changed our platforms at that time, and when I shortly
later switched jobs to the telecommunication area the "whole
world" (sort of) downsized their machine parks to mainly Unix
systems or (partly; later commonly, at least for the Clients)
Windows based systems. And the Unix server installations grew
enormously during the 1990's, then came the big wave of Linux,
and all the providers building their farms on Linux basis. DEC
became invisible [to me] (I was not saying it vanished), similar
like COBOL did not vanish.

Yet I don't understand the relation to Linus Torvalds that was
the source of mentioning VMS. - I mean; only that he dislikes
it is not much of a news. (I've done a few things on a DEC/VAX
with VMS, and I recall it had a verbose hierarchical file system,
a horrible screen VT220, and a (literally!) impressive VT100
keyboard; my fingers still ache when thinking about it. These
days I already had experiences former with Unix (VM/UTS), so I
did know what I got or what I was missing with VMS.)

Janis

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>[...]
>> Quick and dirty editor:
>>
>> $ cat > /tmp/file < /dev/tty
>> line1
>> line2
>> line3
>> ^D
>> $
>> $ cat /tmp/file
>> line1
>> line2
>> line3
>> $
>
>You probably don't need the "< /dev/tty".

True, in most cases. Although I thought it more illustrative
to do it that way in this context.

scott@slp53.sl.home (Scott Lurndal) writes:
> Michael S <already5chosen@yahoo.com> writes:
[...]
>>On only remotely related note, what happens on your system when you
>>want more than 1024 files to be open by one program simultaneously?
>>
>
> $ ulimit -f 2048
>
> Will increase the limit, to any arbitrary value, subject to system
> wide limits configured by the superuser (system manager).

That sets the limit for file size. I think you mean "ulimit -n 2048".

[...]

--
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 31.01.2024 14:10, Michael S wrote:
>> [ DEC's VMS ]
>
> Released in 1977.
> Reached the peak of popularity in mid 1980s, when DEC decided to use
> VAX not just as mini/super-mini, but also as competitor to mainframes,
> effectively killing their earlier mainframe line (PDP-6/10/20).

This is interesting. These days all major players here switched to
Unix systems (in our context specifically AIX and HP-UX), exactly
to exchange the huge sports halls full of mainframe computers to
just a small room full of Unix servers.

> [...]
>
>>> By value, likely still bigger than all Unixen combined.
>>
>> Not sure what (to me strange sounding) ideas you have here.
>
> I can say the same.

Sure, so let me expand. The "By value" was what made me doubt. The
"values" (Real Money) I experienced in the legacy mainframe areas,
in the financial sector (banks and assurance companies); these were
not DECs here, and they were hard to replace. - I know that every
couple years they made their business cases about how they can get
rid of the mainframes, to no avail. (Don't know how it evolved the
past 20 years, though.) And later all the ISP computing power went
in Linux plants, where the money was made. I never observed that
DEC/VMS was of any importance "by value". If it had some value by
means I'm not aware of, I take your word as granted.

Janis

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

>(See for example 'man ksh' Section "Input/Output". But careful; ksh
>has additional non-standard additions. So a peek into the POSIX docs
>might serve you better.)

FWIW, the POSIX shell language was based on a subset of ksh88.

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Michael S <already5chosen@yahoo.com> writes:
>[...]
>>>On only remotely related note, what happens on your system when you
>>>want more than 1024 files to be open by one program simultaneously?
>>>
>>
>> $ ulimit -f 2048
>>
>> Will increase the limit, to any arbitrary value, subject to system
>> wide limits configured by the superuser (system manager).
>
>That sets the limit for file size. I think you mean "ulimit -n 2048".

Yes, thank you.

On Wed, 31 Jan 2024 17:29:30 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>
> I'm not sure why you mentioned 5, whether that's better or worse.
> There's naturally some limit on OS level on the number of parallel
> open file descriptors, but that limit is very high. Mind that you
> can always close unused ones.
>
> Janis
>

Five of each sort, i.e. five inputs and five outputs, sound good to me.

Much more than five of each sort pre-opened by shell sound like too
much. If there exist a need for more than five channels for
communication between complex of programs then this complex of programs
very likely was designed to work together and only together. And then
any intervention of the user into communication between them will
likely do more harm than good.

Of course, I fully expect that usefully using more than three
predefined channels of any particular direction would be very rare, but
I still like five, or at least four, better than three.

As to not using predefined direction and instead just providing a pool
of up to 10 pre-open descriptors, this idea didn't cross my mind in
those particular five minutes that I was writing my initial (yes,
provocative, yes intentionally so) post. Right now I don't want to
think whether I like it or not, because I see no good reasons to
think deeply about this particular water under bridge.

On Wed, 31 Jan 2024 18:19:47 +0100
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:

> On 31.01.2024 14:10, Michael S wrote:
> >> [ DEC's VMS ]
> >
> > Released in 1977.
> > Reached the peak of popularity in mid 1980s, when DEC decided to use
> > VAX not just as mini/super-mini, but also as competitor to
> > mainframes, effectively killing their earlier mainframe line
> > (PDP-6/10/20).
>
> This is interesting. These days all major players here switched to
> Unix systems (in our context specifically AIX and HP-UX), exactly
> to exchange the huge sports halls full of mainframe computers to
> just a small room full of Unix servers.
>

Wikipedia tells me that AIX formally exists since 1986, but in reality
it was just a curiosity until ported to POWER in 1990.
HP-UX sort of existed, but under different name and was not
particularly big until 1990 or 1991.

> > [...]
> >
> >>> By value, likely still bigger than all Unixen combined.
> >>
> >> Not sure what (to me strange sounding) ideas you have here.
> >
> > I can say the same.
>
> Sure, so let me expand. The "By value" was what made me doubt. The
> "values" (Real Money) I experienced in the legacy mainframe areas,
> in the financial sector (banks and assurance companies); these were
> not DECs here, and they were hard to replace. - I know that every
> couple years they made their business cases about how they can get
> rid of the mainframes, to no avail. (Don't know how it evolved the
> past 20 years, though.) And later all the ISP computing power went
> in Linux plants, where the money was made. I never observed that
> DEC/VMS was of any importance "by value". If it had some value by
> means I'm not aware of, I take your word as granted.
>
> Janis
>

DEC was a big company back then, very solidly #2 computers business in
the "West", if we consider Japan as "East'. Somehow I remember a number
14B USD in 1991 or 1992, back when #3 was may be 5 or 6B USD.
And in the second half of the 80s VAX/VMS was the biggest part of DEC
by far. Of course, there always were internal struggles and internal
competition, but it seems less so in this period then in other periods
of DEC's history.

On 31.01.2024 17:26, Michael S 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.

I don't recall to have ever used tcl (maybe once, long ago?),
and I never stumbled across an application (GUI or otherwise)
where I needed scripting and it would have provided Lua. Thus
I cannot help you here, I either don't know it.

All I can say is that the Unix shell was a reliable companion
wherever we had to automate tasks on Unix systems or on Cygwin
enhanced Windows.

Janis

On 31/01/2024 17:38, Keith Thompson wrote:
> David Brown <david.brown@hesbynett.no> writes:
> [...]
>> 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 :-)
>
> It doesn't necessarily do this by default. See the documentation for
> details (which are of course off-topic here).
>

Sure - I investigated to see how it works when I saw it happening, and
there are clearly many possibilities here. But it's nice when you
discover a useful and simple feature of an everyday tool that you never
knew was there.

On 31/01/2024 15:46, Janis Papanagnou wrote:
> 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.

I regularly see it as more symmetrical and clearer to push data left to
right. So I might write "cat infile | grep foo | sort > outfile". Of
course I could use "<" redirection, but somehow it seems more natural to
me to have this flow. I'll use "<" for simpler cases.

But perhaps this is just my habit, and makes little sense to other people.

>
>> 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.
>

Different orders for the files, and different subsets of the same set of
files.

On 31/01/2024 16:22, Scott Lurndal wrote:
> 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.

Or sshfs then "cp -r". There's often more than two tools for the job!

On 31/01/2024 16:25, Janis Papanagnou wrote:
> 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.)
>

I'm not a great fan of shell programming - anything advanced, and I tend
to reach for Python. But I think that is a matter of familiarity and
practice. But if you consider bash programming as difficult to get
right, I'll not argue.

Perl is famously known as a "write-only" language. Sure, it is possible
to write good, clear, maintainable Perl code - but few people do that.

Thus the idea that finding bash cryptic or difficult and using Perl
instead is the joke.

On 31.01.2024 17:47, Janis Papanagnou wrote:
>
> It's just the numbers of file descriptors and whether it's an input >
> or output < channel, or even a read/write channel <> .

In case the typo wasn't obvious and detected as such, please swap them
< input
> output
<> in/out
>> append
<< here-doc
etc.

Janis

On 31/01/2024 19:01, Janis Papanagnou wrote:
> On 31.01.2024 17:26, Michael S 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.
>
> I don't recall to have ever used tcl (maybe once, long ago?),
> and I never stumbled across an application (GUI or otherwise)
> where I needed scripting and it would have provided Lua. Thus
> I cannot help you here, I either don't know it.
>

TCL is - for reasons beyond my ken - the standard scripting language
used by several programmable logic design suites. Your code is a
mixture of VHDL and/or Verilog (and/or higher level HDL languages)
and/or schematic or block diagrams, and it goes through a range of
analysers, test simulators, placement and routing systems. There's
plenty of gui programs involved and non-gui programs, and the whole
thing is tied together with TCL scripting.

I have no idea if that's the kind of system Michael is referring to, but
it is certainly used for that kind of thing.

> All I can say is that the Unix shell was a reliable companion
> wherever we had to automate tasks on Unix systems or on Cygwin
> enhanced Windows.
>

Automation is certainly easier with good scripting - whatever the
language or shell.

David Brown <david.brown@hesbynett.no> writes:
> On 31/01/2024 15:46, Janis Papanagnou wrote:
>> 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.
>
> I regularly see it as more symmetrical and clearer to push data left
> to right. So I might write "cat infile | grep foo | sort > outfile".
> Of course I could use "<" redirection, but somehow it seems more
> natural to me to have this flow. I'll use "<" for simpler cases.
>
> But perhaps this is just my habit, and makes little sense to other people.

You can also use:

< infile grep foo | sort > outfile

Redirections don't have to be written after a command.

--
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 31.01.2024 18:36, Michael S wrote:
> On Wed, 31 Jan 2024 17:29:30 +0100
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>
>> I'm not sure why you mentioned 5, whether that's better or worse.
>> There's naturally some limit on OS level on the number of parallel
>> open file descriptors, but that limit is very high. Mind that you
>> can always close unused ones.
>
> Five of each sort, i.e. five inputs and five outputs, sound good to me.

Well, to me it sounds like an arbitrary number, like four or seven.

But how are these pre-opened FDs then used? To which devices assigned?

We already have what most folks seem to use pre-opened: 0, 1, 2

When I need a new one I couple it with an existing one

exec 3>&1 4>&1 5>&1 ## but why open it in advance per default?

or to a file (where we may have a concrete demand for a second channel)

exec 3< ./my_input
exec 4> /tmp/my_output

and still using channel 0 and 1 (here still connected to the default)
in parallel.

>
> Much more than five of each sort pre-opened by shell sound like too
> much. If there exist a need for more than five channels for
> communication between complex of programs then this complex of programs
> very likely was designed to work together and only together. And then
> any intervention of the user into communication between them will
> likely do more harm than good.
>
> Of course, I fully expect that usefully using more than three
> predefined channels of any particular direction would be very rare, but
> I still like five, or at least four, better than three.

You should have an idea, though, to what they should initially point
to, and why you want them differentiated.

>
> As to not using predefined direction and instead just providing a pool
> of up to 10 pre-open descriptors, this idea didn't cross my mind in
> those particular five minutes that I was writing my initial (yes,
> provocative, yes intentionally so) post. Right now I don't want to
> think whether I like it or not, because I see no good reasons to
> think deeply about this particular water under bridge.

I don't think I understand what you wanted to say here.
(A pool is there, the shell manages it for you.)

As an amendment, in ksh there's also the feature to not manually
assign file descriptor numbers but automatically get them from
the shell by prepending '{var}' to the redirection; here some FD
greater than 10 will be chosen by that shell and it's number
stored in 'var'. This may be useful for applications that may
e.g. serve a couple equivalent communication partners.

Janis