Re: bug-bash Digest, Vol 264, Issue 31

[Wiley Young]

That email I read. :-(

On Sat, Nov 16, 2024, 20:58 <bug-bash-request@gnu.org> wrote:

> Send bug-bash mailing list submissions to
>         bug-bash@gnu.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.gnu.org/mailman/listinfo/bug-bash
> or, via email, send a message with subject or body 'help' to
>         bug-bash-request@gnu.org
>
> You can reach the person managing the list at
>         bug-bash-owner@gnu.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bug-bash digest..."
>
>
> Today's Topics:
>
>    1. redirection / process substitution fails to read a file
>       descriptor (Mike Peters)
>    2. Re: redirection / process substitution fails to read a file
>       descriptor (Greg Wooledge)
>    3. Re: bug-bash Digest, Vol 264, Issue 28 (Wiley Young)
>    4. Re: bug-bash Digest, Vol 264, Issue 28 (G. Branden Robinson)
>    5. Re: bug-bash Digest, Vol 264, Issue 28 (Oğuz)
>    6. Re: redirection / process substitution fails to read a file
>       descriptor (Lawrence Velázquez)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 16 Nov 2024 16:35:05 -0600
> From: Mike Peters <mike@texaspeters.com>
> To: bug-bash@gnu.org
> Subject: redirection / process substitution fails to read a file
>         descriptor
> Message-ID: <f69f2192-026e-4870-a67c-4ede18d62463@texaspeters.com>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
>
> Configuration Information [Automatically generated, do not change]:
> Machine: aarch64
> OS: darwin23.4.0
> Compiler: clang
> Compilation CFLAGS: -DSSH_SOURCE_BASHRC
> -DDEFAULT_LOADABLE_BUILTINS_PATH='/opt/homebrew/Cellar/bash/5.2.37/lib/bash:/usr/loc$
> uname output: Darwin Mikes-Mac-Mini.local 23.3.0 Darwin Kernel Version
> 23.3.0: Wed Dec 20 21:30:27 PST 2023; root:xnu-10002.$
> Machine Type: aarch64-apple-darwin23.4.0
>
> Bash Version: 5.2
> Patch Level: 37
> Release Status: release
>
> Description:
>          Process substitution does not generate properly when pulling from
> another file descriptor, although it works when pulling from a file
> directly. In the below sample shell session, it is expected that
> `<(<test.txt)` would be functionally equivalent to `<(<&3)`.
>
> Repeat-By:
>          > echo foobar > test.txt
>          > echo `< <(<test.txt)`
>          foobar
>          > exec 3<test.txt
>          > cat <&3
>          foobar
>          > exec 3<test.txt
>          > echo `< <(<&3)`
>
>          >
>
>
>
> Mike Peters
>
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Sat, 16 Nov 2024 21:35:43 -0500
> From: Greg Wooledge <greg@wooledge.org>
> To: Mike Peters <mike@texaspeters.com>
> Cc: bug-bash@gnu.org
> Subject: Re: redirection / process substitution fails to read a file
>         descriptor
> Message-ID: <ZzlWf8Fnvl7LPoK1@wooledge.org>
> Content-Type: text/plain; charset=us-ascii
>
> On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote:
> > Description:
> >         Process substitution does not generate properly when pulling
> from another file descriptor, although it works when pulling from a file
> directly. In the below sample shell session, it is expected that
> `<(<test.txt)` would be functionally equivalent to `<(<&3)`.
>
>
> > Repeat-By:
> >         > echo foobar > test.txt
> >         > echo `< <(<test.txt)`
> >         foobar
>
> This is one of the most convoluted things I've seen in a long time.
> You've got a command substitution with < as its command, which is
> equivalent to $(cat ...) as a bash extension.  The argument of </cat
> is a process substitution with a *second* instance of < being used
> as a command.
>
> So, going from the innermost layer outward, you have a process
> substitution which reads a file's contents and dumps it to the
> procsub's FD (the way cat would), and this FD is being treated as
> a filename by a command substitution's </cat which in turn dumps
> the data to the commsub's internal pipe.  The commsub read the
> content from the procsub FD and is replaced by that content, which
> happens to be the string "foobar".  This is passed as an argument
> to echo.
>
> >         > exec 3<test.txt
> >         > cat <&3
> >         foobar
>
> OK.  This part is straightforward.  Note that you used a command, cat,
> to write output.  You didn't simply type <&3 without a command.
>
> >         > exec 3<test.txt
> >         > echo `< <(<&3)`
> >
> >         >
>
> Here, you've got a process substitution with <&3 inside it.  I can
> only guess what this is going to do.  It doesn't follow the standard
> form of < filename which would be treated like cat filename, even though
> it begins with a < character.
>
> I'm guessing that the parser sees the <& and decides *not* to treat
> this as a shortcut of cat with &3 as a filename.  Therefore, the only
> thing the parser can do is treat this as an empty command with a <&3
> redirection attached to it.
>
> So, your process runs an empty command with a stdin redirection,
> which produces no output.  The procsub therefore receives no data.
> So the filename that the procsub is replaced by may as well be a symlink
> to /dev/null.
>
> Then, you have the command substitution with < followed by that
> filename, which contains no data.  The commsub produces no output,
> so it's replaced by nothing.  (The commsub is not quoted, so it
> simply vanishes, leaving echo with no arguments.)
>
> echo is executed with no arguments, so it writes a newline to stdout.
>
> If you expected the inner process substitution to generate output,
> then there needs to be a command of some kind inside it, and that
> command should write to stdout.  The obvious pick would be cat.
>
> In the *first* segment of code, your inner process substitution had
> the < command inside it, which acts like cat, because of a bash
> extension.  You're missing that in the final code segment.
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 16 Nov 2024 18:52:12 -0800
> From: Wiley Young <wyeth2485@gmail.com>
> To: bug-bash@gnu.org
> Subject: Re: bug-bash Digest, Vol 264, Issue 28
> Message-ID:
>         <CAGnujaOTJZih58WF8GwZSgh7sRj+=
> 7Ru9dv702iXC8TDr-1NMg@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> | From: Martin D Kealey
>
> |   "In the general case I agree; man
>
> | pages should be reference
>
> | manuals, not tutorials...."
>
>   We should value others' contributions.
>   Most people, when they read something that they don't yet understand, if
> they wish to understand it, will seek out a more accessible text.
>   You lost me at "envisaged." Sorry, it didn't have anything to do medieval
> plate armor helmets.
>   Wiley
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 16 Nov 2024 21:31:26 -0600
> From: "G. Branden Robinson" <g.branden.robinson@gmail.com>
> To: bug-bash@gnu.org
> Subject: Re: bug-bash Digest, Vol 264, Issue 28
> Message-ID: <20241117033126.jpjvaegplgvk55fw@illithid>
> Content-Type: text/plain; charset="utf-8"
>
> At 2024-11-16T18:52:12-0800, Wiley Young wrote:
> > | From: Martin D Kealey
> >
> > |   "In the general case I agree; man
> >
> > | pages should be reference
> >
> > | manuals, not tutorials...."
> >
> >   We should value others' contributions.
>
> This statement implies that we lack a means of evaluating contributions.
>
> They either happen, or they do not, and they are all of equal value.
>
> In how many aspects of life do you apply this principle to human effort?
>
> >   Most people, when they read something that they don't yet understand,
> if
> > they wish to understand it, will seek out a more accessible text.
> >   You lost me at "envisaged." Sorry, it didn't have anything to do
> medieval
> > plate armor helmets.
>
> The dictionary you're using may be excessively recondite for you; seek
> out a more accessible one.
>
> Regards,
> Branden
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 833 bytes
> Desc: not available
> URL: <
> https://lists.gnu.org/archive/html/bug-bash/attachments/20241116/5a0b2871/attachment.sig
> >
>
> ------------------------------
>
> Message: 5
> Date: Sun, 17 Nov 2024 07:46:59 +0300
> From: Oğuz <oguzismailuysal@gmail.com>
> To: "G. Branden Robinson" <g.branden.robinson@gmail.com>
> Cc: "bug-bash@gnu.org" <bug-bash@gnu.org>
> Subject: Re: bug-bash Digest, Vol 264, Issue 28
> Message-ID:
>         <
> CAH7i3LqW++yNnAqA5n2bKUi-osEv1Nha0nquyA8Y_r3FjEYOjg@mail.gmail.com>
> Content-Type: text/plain; charset="UTF-8"
>
> On Sunday, November 17, 2024, G. Branden Robinson <
> g.branden.robinson@gmail.com> wrote:
> >
> > recondite
> >
>
> That's a recondite word, isn't it Sunday where you live?
>
>
> --
> Oğuz
>
>
> ------------------------------
>
> Message: 6
> Date: Sat, 16 Nov 2024 23:56:59 -0500
> From: Lawrence Velázquez <vq@larryv.me>
> To: "Mike Peters" <mike@texaspeters.com>
> Cc: "Greg Wooledge" <greg@wooledge.org>, bug-bash@gnu.org
> Subject: Re: redirection / process substitution fails to read a file
>         descriptor
> Message-ID: <6d03bbcc-abc7-4056-97ba-9629408765cc@app.fastmail.com>
> Content-Type: text/plain
>
> On Sat, Nov 16, 2024, at 9:35 PM, Greg Wooledge wrote:
> > On Sat, Nov 16, 2024 at 16:35:05 -0600, Mike Peters wrote:
> >> Description:
> >>         Process substitution does not generate properly when pulling
> from another file descriptor, although it works when pulling from a file
> directly. In the below sample shell session, it is expected that
> `<(<test.txt)` would be functionally equivalent to `<(<&3)`.
> >
> >
> >> Repeat-By:
> >>         > echo foobar > test.txt
> >>         > echo `< <(<test.txt)`
> >>         foobar
>
> Be aware that <(<file) is undocumented and was removed [1] after
> Emanuele brought it up [2]; it will not work in future releases.
> However, the "issue" does affect command substitutions:
>
>         $ echo foobar >test.txt
>         $ echo "$(<test.txt)"
>         foobar
>         $ exec 3<test.txt
>         $ echo "$(<&3)"
>
>         $
>
> [1]
> https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=d3e86e66ce857a8dc02e3116fd98b6e5b34d6364
> [2] https://lists.gnu.org/archive/html/bug-bash/2024-07/msg00045.html
>
>
> > I'm guessing that the parser sees the <& and decides *not* to treat
> > this as a shortcut of cat with &3 as a filename.  Therefore, the only
> > thing the parser can do is treat this as an empty command with a <&3
> > redirection attached to it.
>
> As I understand the code [3][4], <file ("r_input_direction") is a
> candidate for the "cat" optimization, <&n ("r_duplicating_input")
> isn't, and the decision is made after parsing, so there's no way
> &n could be interpreted as a filename.
>
> Note that the actual documentation for this feature doesn't say or
> imply that <&n should work:
>
>         The command substitution $(cat file) can be replaced by the
>         equivalent but faster $(< file).
>
> This reading doesn't make much sense:
>
>         The command substitution $(cat &n) can be replaced by the
>         equivalent but faster $(< &n).
>
> There might be an argument for it if the documentation read:
>
>         The command substitution $(cat <file) can be replaced by
>         the equivalent but faster $(<file).
>
> But it doesn't.
>
> [3]
> https://git.savannah.gnu.org/cgit/bash.git/tree/builtins/evalstring.c?h=devel&id=fa68e6da80970c302948674369d278164a33ed39#n198
> [4]
> https://git.savannah.gnu.org/cgit/bash.git/tree/make_cmd.c?h=devel&id=fa68e6da80970c302948674369d278164a33ed39#n663
>
> --
> vq
>
>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bug-bash mailing list
> bug-bash@gnu.org
> https://lists.gnu.org/mailman/listinfo/bug-bash
>
>
> ------------------------------
>
> End of bug-bash Digest, Vol 264, Issue 31
> *****************************************
>