That email I read. :-( On Sat, Nov 16, 2024, 20:58 <bug-bash-requ...@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-requ...@gnu.org > > You can reach the person managing the list at > bug-bash-ow...@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 <m...@texaspeters.com> > To: bug-bash@gnu.org > Subject: redirection / process substitution fails to read a file > descriptor > Message-ID: <f69f2192-026e-4870-a67c-4ede18d62...@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 <g...@wooledge.org> > To: Mike Peters <m...@texaspeters.com> > Cc: bug-bash@gnu.org > Subject: Re: redirection / process substitution fails to read a file > descriptor > Message-ID: <zzlwf8fnvl7lp...@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 <wyeth2...@gmail.com> > To: bug-bash@gnu.org > Subject: Re: bug-bash Digest, Vol 264, Issue 28 > Message-ID: > <CAGnujaOTJZih58WF8GwZSgh7sRj+= > 7ru9dv702ixc8tdr-1...@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.robin...@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 <oguzismailuy...@gmail.com> > To: "G. Branden Robinson" <g.branden.robin...@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_r3fjey...@mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > On Sunday, November 17, 2024, G. Branden Robinson < > g.branden.robin...@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 <v...@larryv.me> > To: "Mike Peters" <m...@texaspeters.com> > Cc: "Greg Wooledge" <g...@wooledge.org>, bug-bash@gnu.org > Subject: Re: redirection / process substitution fails to read a file > descriptor > Message-ID: <6d03bbcc-abc7-4056-97ba-962940876...@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 > ***************************************** >
