Re: Likely Bash bug
Date:Tue, 16 Mar 2021 22:08:17 -0500 From:Dennis Williamson Message-ID: | In any case this points to larger chunks being more efficient. This is not news, doing reads (or writes) using bigger buffers (more bytes at a time) means less system calls, and compared to almost anything else that happens, system calls are expensive - doing less will make things run faster. Unfortunately, it can also alter the semantics of what is happening - whether it does or not entirely depends upon the application. Lastly, if you really care about any of this - that is, if it really matters to something more than your ego - then you shouldn't be writing in shell at all, but using a compiled language. Lots of things in shell involve running other programs, and running another program usually involves large numbers of system calls (including fork() and exec() - two of the most costly that exist). Write shell scripts to do things where all the time is either spent waiting for something to happen (like the user to type the next command) or in some other program that the shell runs (like a compiler, or document processor) and no-one cares just how efficient the shell might be in making all of that happen, as in the overall scheme of things it makes no difference (kind of like worrying how quickly you can drive down your driveway to get in or out of your house when the real issue is how long it takes you to get to/from work). kre
Re: Likely Bash bug
Date:Tue, 16 Mar 2021 18:01:24 -0400 From:Jay via Bug reports for the GNU Bourne Again SHell Message-ID: <86f1f224-2930-ee73-5431-6e130d92f...@aim.com> First, thanks Lawrence for the translation from RTF, I am one of the people he intended to help... The RTF form I was going to simply ignore. |The system is modern Intel computer, 2018 to 2019 configured in BIOS |mode. That should make no difference. | Operating system is BionicPup64 8.0. That might. More importantly is probably whatever package management system it uses. I have no idea what the "ash" the bug report refers to is (there is an ancient shell of that name, but I cannot imagine any distribution including that, instead of one of its bug fixed and updated successors, like say, dash) but it seems to me as if the problem here relates to whatever package manager was used, that doesn't keep track of what files various packages touch, and allows one package to overwrite another's files. That is, not a bash problem at all. The OS might also have issues, if doing things to files can cause it to crash, but it is more likely, that ash, whatever it is, did something which caused a problem, when some of its files were destroyed by the package manager. Finally, it is generally not a good idea to do anything as "root" (or using sudo to the same effect) if you aren't 100% confident in what you are doing. kre
Re: Changing the way bash expands associative array subscripts
Date:Tue, 16 Mar 2021 13:26:30 +0100 From:Alex fxmbsw7 Ratchev Message-ID: | no idea about your internal rules of keyword and builtin but clearly its | gotta parse it at most 1. level otherwise its big security fault isnt it No, it isn't. No more than cd /; rm -fr * is a "big security fault" (in the shell). Users who do stupid things might be a big security fault, but it is not the shell's job to stop that (if you think you need that help, find some shell that still implements restricted mode, if there are any (does bash?) and use that, then you'll be fairly well protected - you also won't be able to do much). | its a shell fuctionality keyword, unset, so .. Lots of things are what seems to be shell functionality, that changes nothing. If you don't want word splitting, add quotes. Your responsibility. g...@wooledge.org said: | I would not complain if unset became a shell keyword, and had a complete | revamp of its behavior. I would. keywords cannot be overridden by functions, and so should be used only where absolutely required (which means, really, that in order to work, they require a magic syntax, that the shell must implement). And yes '[[' being a keyword, is, IMO, a mistake. unset requires no more than regular shell parsing, and should be left alone. kre
Re: Likely Bash bug
. On Tue, Mar 16, 2021, 10:22 PM Lawrence Velázquez wrote: > > On Mar 16, 2021, at 11:08 PM, Dennis Williamson < > dennistwilliam...@gmail.com> wrote: > > > > I've been playing with your optimized code changing the read to grab data > > in chunks like some of the other optimized code does - thus extending > your > > move from by-word to by-line reading to reading a specified larger number > > of characters. > > > > IFS= read -r -N 4096 var > > > > And appending the result of a regular read to end at a newline. This > seemed > > to cut about 20% off the time. But I get different counts than your code. > > I've tried using read without specifying a variable and using the > resulting > > $REPLY to preserve whitespace but the counts still didn't match. > > > > In any case this points to larger chunks being more efficient. > > Wrong thread? > > vq Oops
Re: Likely Bash bug
> On Mar 16, 2021, at 11:08 PM, Dennis Williamson > wrote: > > I've been playing with your optimized code changing the read to grab data > in chunks like some of the other optimized code does - thus extending your > move from by-word to by-line reading to reading a specified larger number > of characters. > > IFS= read -r -N 4096 var > > And appending the result of a regular read to end at a newline. This seemed > to cut about 20% off the time. But I get different counts than your code. > I've tried using read without specifying a variable and using the resulting > $REPLY to preserve whitespace but the counts still didn't match. > > In any case this points to larger chunks being more efficient. Wrong thread? vq
Re: is it a bug that PWD=whatever sets PS1's \w to that regardless
Date:Tue, 16 Mar 2021 09:31:24 -0400
From:Chet Ramey
Message-ID: <31aff163-9e61-d34a-be79-40c7e09a8...@case.edu>
| If you want to set PWD instead of letting cd/pushd/popd manage it,
| all bets are off.
I agree with that as far as what you get when you expand $PWD (even the
pwd command, so using `pwd` as an alternative if PWD has been manually
set is not necessarily going to work), and even the way the cd command
works, but the bash man page says:
\w the current working directory, with $HOME abbreviated
with a tilde (uses the value of the PROMPT_DIRTRIM
variable)
Nothing about $PWD there, it should be the current working directory,
according to that definition, and one thing that changing PWD does not
do is change the current working directory.
Of course, the simple fix to this is to change the man page, so refer
to $PWD instead of "the current working directory".
| Just like setting HOME changes tilde expansion.
It does, but that's not really an analogy, ~/ is defined to be ${HOME}/
so if changing HOME did not have that effect then ~ expansion would be
broken. If changing HOME had any effect on ~kre/ (given that the
relevant user name is used, such that it should produce what is normally
in an unaltered $HOME) however, then that would be a problem.
kre
Re: Likely Bash bug
On Tue, Mar 16, 2021, 6:19 PM Lawrence Velázquez wrote: > > On Mar 16, 2021, at 6:01 PM, Jay via Bug reports for the GNU Bourne > Again SHell wrote: > > > > Hello, > > > > I have been using/exploring Linux for ~ 2yrs; have corrupted a couple > > systems more than once either through their instability with libraries > > or just excess stress. > > > > I don't consider current case to be either of the above; see attached. > > > > The system is modern Intel computer, 2018 to 2019 configured in BIOS > > mode. Operating system is BionicPup64 8.0. > > > > Best Regards. > > > > Reproduced below for anyone who doesn't feel like reading a bug > report out of an RTF document. > > vq > > > > From: root > To: bug-bash@gnu.org,b...@packages.debian.org > Subject: [ash--bash interference (for reference)] > > Configuration Information [Automatically generated, do not change]: > Machine: x86_64 > OS: linux-gnu > Compiler: gcc > Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' > -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' > -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL > -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -Wdate-time > -D_FORTIFY_SOURCE=2 -g -O2 > -fdebug-prefix-map=/build/bash-vEMnMR/bash-4.4.18=. > -fstack-protector-strong -Wformat -Werror=format-security -Wall > -Wno-parentheses -Wno-format-security > uname output: Linux puppypc23046 4.19.23 #1 SMP Tue Feb 19 15:07:58 GMT > 2019 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 4.4 > Patch Level: 19 > Release Status: release > > Description: > [Original ash executable/script reduced to 4 bytes after download > of "Clonezilla" > through Puppy Package Manager. Reboot of system hung at > 'switching-layers'.] > > Repeat-By: > [Believed occurred after an ash co-dependency download as part of > install.] > > Fix: > [Noted xwin errors relating to ash on shutdown; had backup > savefile. Compared /bin and saw the difference. Replaced ash from backup > file to working folder.] > I've been playing with your optimized code changing the read to grab data in chunks like some of the other optimized code does - thus extending your move from by-word to by-line reading to reading a specified larger number of characters. IFS= read -r -N 4096 var And appending the result of a regular read to end at a newline. This seemed to cut about 20% off the time. But I get different counts than your code. I've tried using read without specifying a variable and using the resulting $REPLY to preserve whitespace but the counts still didn't match. In any case this points to larger chunks being more efficient. >
Re: Likely Bash bug
> On Mar 16, 2021, at 6:01 PM, Jay via Bug reports for the GNU Bourne Again > SHell wrote: > > Hello, > > I have been using/exploring Linux for ~ 2yrs; have corrupted a couple > systems more than once either through their instability with libraries > or just excess stress. > > I don't consider current case to be either of the above; see attached. > > The system is modern Intel computer, 2018 to 2019 configured in BIOS > mode. Operating system is BionicPup64 8.0. > > Best Regards. > Reproduced below for anyone who doesn't feel like reading a bug report out of an RTF document. vq From: root To: bug-bash@gnu.org,b...@packages.debian.org Subject: [ash--bash interference (for reference)] Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -fdebug-prefix-map=/build/bash-vEMnMR/bash-4.4.18=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux puppypc23046 4.19.23 #1 SMP Tue Feb 19 15:07:58 GMT 2019 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.4 Patch Level: 19 Release Status: release Description: [Original ash executable/script reduced to 4 bytes after download of "Clonezilla" through Puppy Package Manager. Reboot of system hung at 'switching-layers'.] Repeat-By: [Believed occurred after an ash co-dependency download as part of install.] Fix: [Noted xwin errors relating to ash on shutdown; had backup savefile. Compared /bin and saw the difference. Replaced ash from backup file to working folder.]
Likely Bash bug
Hello, I have been using/exploring Linux for ~ 2yrs; have corrupted a couple systems more than once either through their instability with libraries or just excess stress. I don't consider current case to be either of the above; see attached. The system is modern Intel computer, 2018 to 2019 configured in BIOS mode. Operating system is BionicPup64 8.0. Best Regards. Bash-issue.rtf Description: MS-Word document
Re: [Patch] distclean should not rm lib/readline/doc/Makefile
On 3/16/21 11:38 AM, Mike Jonkmans wrote: A 'make distclean' removes lib/readline/doc/Makefile It is a handmade Makefile, so probably should not be removed. Thanks for the report. It shouldn't be in the bash distribution at all; it exists only for my convenience. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: so-called pipe files (sh-np-*) do not get deleted when processes close.
On 16/03/2021 16:21, Chet Ramey wrote: On 3/16/21 11:07 AM, Michael Felt wrote: On 16/03/2021 14:38, Chet Ramey wrote: On 3/16/21 8:04 AM, Michael Felt wrote: Decided to give bash-5.1 a try. I doubt it is major, but I get as far as: "../../../src/bash-5.1.0/lib/sh/tmpfile.c", line 289.11: 1506-068 (W) Operation between types "char*" and "int" is not allowed. ld: 0711-317 ERROR: Undefined symbol: .mkdtemp Then how does configure find it? It's a POSIX function, and that file includes the appropriate headers. Haven't looked at configure yet - but do not find it in the usual places: root@x065:[/data/prj/gnu/bash/bash-5.0.18]grep mkdtemp /usr/include/*.h root@x065:[/data/prj/gnu/bash/bash-5.0.18]grep mkdtemp /usr/include/sys/*.h Also, not found on AIX 6.1 (TL9), but did find on AIX 7.1 TL4. Sure, but configure checks for it, and bash only uses mkdtemp if configure finds it. Why does configure find it? Not sure. I'll have time again Thursday. Will be back. OpenPGP_0x722BFDB61F396FC2.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
[Patch] distclean should not rm lib/readline/doc/Makefile
A 'make distclean' removes lib/readline/doc/Makefile It is a handmade Makefile, so probably should not be removed. Idem for maintainer-clean. Regards, Mike Jonkmans diff --git lib/readline/doc/Makefile lib/readline/doc/Makefile index af5ee3e5..6bc2e5ea 100644 --- lib/readline/doc/Makefile +++ lib/readline/doc/Makefile @@ -130,14 +130,12 @@ clean: distclean: clean $(RM) $(CREATED_DOCS) $(RM) $(INTERMEDIATE_OBJ) - $(RM) Makefile mostlyclean: clean maintainer-clean: clean $(RM) $(CREATED_DOCS) $(RM) $(INTERMEDIATE_OBJ) - $(RM) Makefile install: @echo "This documentation should not be installed."
Re: so-called pipe files (sh-np-*) do not get deleted when processes close.
On 3/16/21 11:07 AM, Michael Felt wrote: On 16/03/2021 14:38, Chet Ramey wrote: On 3/16/21 8:04 AM, Michael Felt wrote: Decided to give bash-5.1 a try. I doubt it is major, but I get as far as: "../../../src/bash-5.1.0/lib/sh/tmpfile.c", line 289.11: 1506-068 (W) Operation between types "char*" and "int" is not allowed. ld: 0711-317 ERROR: Undefined symbol: .mkdtemp Then how does configure find it? It's a POSIX function, and that file includes the appropriate headers. Haven't looked at configure yet - but do not find it in the usual places: root@x065:[/data/prj/gnu/bash/bash-5.0.18]grep mkdtemp /usr/include/*.h root@x065:[/data/prj/gnu/bash/bash-5.0.18]grep mkdtemp /usr/include/sys/*.h Also, not found on AIX 6.1 (TL9), but did find on AIX 7.1 TL4. Sure, but configure checks for it, and bash only uses mkdtemp if configure finds it. Why does configure find it? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: so-called pipe files (sh-np-*) do not get deleted when processes close.
On 16/03/2021 14:38, Chet Ramey wrote: On 3/16/21 8:04 AM, Michael Felt wrote: Decided to give bash-5.1 a try. I doubt it is major, but I get as far as: "../../../src/bash-5.1.0/lib/sh/tmpfile.c", line 289.11: 1506-068 (W) Operation between types "char*" and "int" is not allowed. ld: 0711-317 ERROR: Undefined symbol: .mkdtemp Then how does configure find it? It's a POSIX function, and that file includes the appropriate headers. Haven't looked at configure yet - but do not find it in the usual places: root@x065:[/data/prj/gnu/bash/bash-5.0.18]grep mkdtemp /usr/include/*.h root@x065:[/data/prj/gnu/bash/bash-5.0.18]grep mkdtemp /usr/include/sys/*.h Also, not found on AIX 6.1 (TL9), but did find on AIX 7.1 TL4. Hope this helps, Michael OpenPGP_0x722BFDB61F396FC2.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
Re: so-called pipe files (sh-np-*) do not get deleted when processes close.
On 3/16/21 8:04 AM, Michael Felt wrote: Decided to give bash-5.1 a try. I doubt it is major, but I get as far as: "../../../src/bash-5.1.0/lib/sh/tmpfile.c", line 289.11: 1506-068 (W) Operation between types "char*" and "int" is not allowed. ld: 0711-317 ERROR: Undefined symbol: .mkdtemp Then how does configure find it? It's a POSIX function, and that file includes the appropriate headers. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: is it a bug that PWD=whatever sets PS1's \w to that regardless
okay, cool, thank you for valuable infos =)) On Tue, Mar 16, 2021 at 2:31 PM Chet Ramey wrote: > On 3/16/21 6:23 AM, Alex fxmbsw7 Ratchev wrote: > > .. ? > > > > # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 == > > 2021-03-16+11:22:2920 ) # > > PWD=/bla > > No. If you want to set PWD instead of letting cd/pushd/popd manage it, > all bets are off. > > Just like setting HOME changes tilde expansion. > > > -- > ``The lyf so short, the craft so long to lerne.'' - Chaucer > ``Ars longa, vita brevis'' - Hippocrates > Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/ >
Re: is it a bug that PWD=whatever sets PS1's \w to that regardless
On 3/16/21 6:23 AM, Alex fxmbsw7 Ratchev wrote: .. ? # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 == 2021-03-16+11:22:2920 ) # PWD=/bla No. If you want to set PWD instead of letting cd/pushd/popd manage it, all bets are off. Just like setting HOME changes tilde expansion. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Changing the way bash expands associative array subscripts
as for shell keyword be more important and vital to shells, than more external [or so?] built ins unset -v var ## very internal to shell var extension thatss not possible to disable [[ .. ## a test for strings or so containing .. it would not make sense to have unset be lower than [[ On Tue, Mar 16, 2021 at 1:39 PM Alex fxmbsw7 Ratchev wrote: > i guess shell-keyword all then :)) > > On Tue, Mar 16, 2021 at 1:37 PM Greg Wooledge wrote: > >> On Tue, Mar 16, 2021 at 01:26:30PM +0100, Alex fxmbsw7 Ratchev wrote: >> > no idea about your internal rules of keyword and builtin >> >> unicorn:~$ type [ >> [ is a shell builtin >> unicorn:~$ type [[ >> [[ is a shell keyword >> >> You know how you're allowed to omit quotes inside [[ but not inside [ ? >> That's because [[ has magical powers. It's a "shell keyword". It has >> its own special rules. >> >> > but clearly its >> > gotta parse it at most 1. level otherwise its big security fault isnt it >> > its a shell fuctionality keyword, unset, so .. >> >> I would not complain if unset became a shell keyword, and had a complete >> revamp of its behavior. As long as we're willing to break backward >> compatibility, which Chet seems like he's aiming to do anyway >> >>
Re: Changing the way bash expands associative array subscripts
i guess shell-keyword all then :)) On Tue, Mar 16, 2021 at 1:37 PM Greg Wooledge wrote: > On Tue, Mar 16, 2021 at 01:26:30PM +0100, Alex fxmbsw7 Ratchev wrote: > > no idea about your internal rules of keyword and builtin > > unicorn:~$ type [ > [ is a shell builtin > unicorn:~$ type [[ > [[ is a shell keyword > > You know how you're allowed to omit quotes inside [[ but not inside [ ? > That's because [[ has magical powers. It's a "shell keyword". It has > its own special rules. > > > but clearly its > > gotta parse it at most 1. level otherwise its big security fault isnt it > > its a shell fuctionality keyword, unset, so .. > > I would not complain if unset became a shell keyword, and had a complete > revamp of its behavior. As long as we're willing to break backward > compatibility, which Chet seems like he's aiming to do anyway > >
Re: Changing the way bash expands associative array subscripts
On Tue, Mar 16, 2021 at 01:26:30PM +0100, Alex fxmbsw7 Ratchev wrote: > no idea about your internal rules of keyword and builtin unicorn:~$ type [ [ is a shell builtin unicorn:~$ type [[ [[ is a shell keyword You know how you're allowed to omit quotes inside [[ but not inside [ ? That's because [[ has magical powers. It's a "shell keyword". It has its own special rules. > but clearly its > gotta parse it at most 1. level otherwise its big security fault isnt it > its a shell fuctionality keyword, unset, so .. I would not complain if unset became a shell keyword, and had a complete revamp of its behavior. As long as we're willing to break backward compatibility, which Chet seems like he's aiming to do anyway
Re: is it a bug that PWD=whatever sets PS1's \w to that regardless
but is it a bug its a bug to use heavy subshells for such i understand the addment of this case tho On Tue, Mar 16, 2021 at 1:23 PM Chris Elvidge wrote: > On 16/03/2021 10:23 am, Alex fxmbsw7 Ratchev wrote: > > .. ? > > > > # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 == > > 2021-03-16+11:22:2920 ) # > > PWD=/bla > > # root /bla ( 0 @ 2 ) boost ( 42148 @ 1615890199.128728 == > > 2021-03-16+11:23:1920 ) # > > > > Yes, it seems \w (and \W) take their values from $PWD > If you want to register the current directory in $PS1 regardless, change > \w to `pwd` > > -- > Chris Elvidge > England > > >
Re: Changing the way bash expands associative array subscripts
no idea about your internal rules of keyword and builtin but clearly its gotta parse it at most 1. level otherwise its big security fault isnt it its a shell fuctionality keyword, unset, so .. On Tue, Mar 16, 2021 at 1:21 PM Greg Wooledge wrote: > On Tue, Mar 16, 2021 at 09:24:01AM +0100, Alex fxmbsw7 Ratchev wrote: > > it doesnt make me much sense that unset -v assoc[$key] gives syntax error > > or so.. > > Think of it this way: what would happen if you had a filename in a > variable -- say, $file -- and you ran this command: > > rm -f $file > > You'd expect that to fail, right? Of course. > > unset -v assoc[$key] fails for exactly the same reason. unset does not > have any magical powers. It's only a shell builtin, NOT a shell keyword. > Therefore, the standard shell rules apply. Expansions occur first, > followed by word splitting, which cause a list of argument words to be > created and passed as arguments to the builtin. > > key='two words' > unset -v assoc[$key] > > ==> 'unset' '-v' 'assoc[two' 'words]' > > You can even use set -x to see this in action: > > unicorn:~$ key='two words' > unicorn:~$ set -x > unicorn:~$ unset -v assoc[$key] > + unset -v 'assoc[two' 'words]' > bash: unset: `assoc[two': not a valid identifier > bash: unset: `words]': not a valid identifier > >
Re: is it a bug that PWD=whatever sets PS1's \w to that regardless
On 16/03/2021 10:23 am, Alex fxmbsw7 Ratchev wrote: .. ? # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 == 2021-03-16+11:22:2920 ) # PWD=/bla # root /bla ( 0 @ 2 ) boost ( 42148 @ 1615890199.128728 == 2021-03-16+11:23:1920 ) # Yes, it seems \w (and \W) take their values from $PWD If you want to register the current directory in $PS1 regardless, change \w to `pwd` -- Chris Elvidge England
Re: Changing the way bash expands associative array subscripts
On Tue, Mar 16, 2021 at 09:24:01AM +0100, Alex fxmbsw7 Ratchev wrote: > it doesnt make me much sense that unset -v assoc[$key] gives syntax error > or so.. Think of it this way: what would happen if you had a filename in a variable -- say, $file -- and you ran this command: rm -f $file You'd expect that to fail, right? Of course. unset -v assoc[$key] fails for exactly the same reason. unset does not have any magical powers. It's only a shell builtin, NOT a shell keyword. Therefore, the standard shell rules apply. Expansions occur first, followed by word splitting, which cause a list of argument words to be created and passed as arguments to the builtin. key='two words' unset -v assoc[$key] ==> 'unset' '-v' 'assoc[two' 'words]' You can even use set -x to see this in action: unicorn:~$ key='two words' unicorn:~$ set -x unicorn:~$ unset -v assoc[$key] + unset -v 'assoc[two' 'words]' bash: unset: `assoc[two': not a valid identifier bash: unset: `words]': not a valid identifier
Re: so-called pipe files (sh-np-*) do not get deleted when processes close.
On 11/03/2021 22:27, Chet Ramey wrote: On 3/11/21 3:55 PM, Michael Felt (aixtools) wrote: Sent from my iPhone On 11 Mar 2021, at 18:15, Chet Ramey wrote: On 3/11/21 11:28 AM, Michael Felt wrote: Hi, Issue: AdoptOpenJDK build process makes bash calls in a particular way. An abbreviated (shorter pathnames) example is: ``` bash-5.0$ /usr/bin/printf "Building targets 'product-images legacy-jre-image test-image' in configuration 'aix-ppc64-normal-server-release'\n" > >(/usr/bin/tee -a /home/aixtools/build.log) 2> >(/usr/bin/tee -a /home/aixtools/build.log >&2) Building targets 'product-images legacy-jre-image test-image' in configuration 'aix-ppc64-normal-server-release' I believe this is fixed in bash-5.1. Would it be difficult to give me a hint for 5.0. I could test further now i have a command that generates the issue. I can't reproduce it, but you can look at unlink_all_fifos() in bash-5.1. It's defined in subst.c and called in shell.c. FYI: Been digging in bash-5.0.18 - learning... Decided to give bash-5.1 a try. I doubt it is major, but I get as far as: "../../../src/bash-5.1.0/lib/sh/tmpfile.c", line 289.11: 1506-068 (W) Operation between types "char*" and "int" is not allowed. ld: 0711-317 ERROR: Undefined symbol: .mkdtemp ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more information. make: 1254-004 The error code from the last command is 8. Using AIX 5.3 TL12 and xlc/xlC-v11, and a largely stripped system Of other OSS). I'll also give it a go on a more public server. Michael Probably because the process substitution does not exit before the shell does. I was hoping that is what the wait routines were for. Also noticed that the second fifo never gets a pid. Bash doesn't wait for asynchronous processes before it exits unless you use `wait'. OpenPGP_0x722BFDB61F396FC2.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature
is it a bug that PWD=whatever sets PS1's \w to that regardless
.. ? # root ~/ogt2/confs ( 0 @ 2 ) boost ( 42098 @ 1615890149.004363 == 2021-03-16+11:22:2920 ) # PWD=/bla # root /bla ( 0 @ 2 ) boost ( 42148 @ 1615890199.128728 == 2021-03-16+11:23:1920 ) #
Re: Changing the way bash expands associative array subscripts
hello, excuse my bad english
your sample code that you write what it should produce you propose for the
future so ?
it doesnt make me much sense that unset -v assoc[$key] gives syntax error
or so..
also about the assoc_expand_once i dont understand
cant it be as written, expand_once ( maybe _at_beginning_only )
set unset -v assoc[$key] would expand key as alike the first argument of
[[ comparision
to a string $( echo foo ) .. no more further .. .. and work out .. .. ?
i dont understand im sorry
On Tue, Mar 16, 2021 at 7:03 AM Lawrence Velázquez wrote:
> > On Mar 15, 2021, at 9:03 PM, Léa Gris wrote:
> >
> > Please excuse my profanity of mentioning zsh in this list, but I really
> think features and behavior convergence can benefit end users in multiple
> ways, especially when expanding beyond the POSIX sh scope.
> >
> > What direction has taken zsh with expanding associative array indexes?
>
> Broadly speaking, zsh treats subscript expressions as if they are
> double-quoted, but it does not perform arithmetic expansion on associative
> array indices (although subscript expressions must still adhere to related
> parsing rules).
>
> % zsh --version; echo
> zsh 5.8 (x86_64-apple-darwin18.7.0)
>
> % cat /tmp/demo1
> # Chet's example modified to highlight certain behaviors
> foo() {
> echo uname >&2
> echo +1
> }
>
> declare -A assoc
> key='x$(foo)]=1,b[1$(foo)'
>
> assoc[$key]=0
> declare -p assoc b
>
> % zsh -f /tmp/demo1
> /tmp/demo1:declare:10: no such variable: b
> typeset -A assoc=( ['x$(foo)]=1,b[1$(foo)']=0 )
>
> However, it does perform multiple expansions in arithmetic contexts.
>
> % cat /tmp/demo2
> # Chet's example modified to highlight certain behaviors
> foo() {
> echo uname >&2
> echo +1
> }
>
> declare -A assoc
> key='x$(foo)]=1,b[1$(foo)'
>
> (( assoc[$key]++ ))
> declare -p assoc b
>
> % zsh -f /tmp/demo2
> uname
> uname
> typeset -A assoc=( [x+1]=1 )
> typeset -a b=( '' 1 )
>
> Furthermore, "as if they are double-quoted" is rather literal. (Special
> handling allows the use of a["foo"] instead of a[\"foo\"].)
>
> % cat /tmp/demo3
> declare -A a
> key='$(echo foo)'
> a[$key]=1
> a['$key']=2
> a["foo"]=3
>
> declare -p a
>
> % zsh -f /tmp/demo3
> typeset -A a=( ['"foo"']=3 ['$(echo foo)']=1 [\''$(echo foo)'\']=2
> )
>
> If we tweak the preamble to create the intended array (and disable NOMATCH
> to treat failed filename generation as bash does), the unset commands work
> the same as in Chet's proposal.
>
> % cat /tmp/demo4
> declare -A a
> key='$(echo foo)'
> a[$key]=1
> a[\$key]=2
> a[foo]=3
>
> # Avoid Chet's intentional error because it's difficult to get zsh
> to
> # imitate it faithfully.
> #unset -v a[$key]
> declare -p a
>
> # unsets element with key $key
> unset -v a['$key']
> declare -p a
>
> # unsets element with key $(echo foo)
> unset -v a["$key"]
> declare -p a
>
> # unsets element with key foo
> eval unset -v a\["$key"\]
> declare -p a
>
> % zsh -f +o NOMATCH /tmp/demo4
> typeset -A a=( ['$(echo foo)']=1 ['$key']=2 [foo]=3 )
> typeset -A a=( ['$(echo foo)']=1 [foo]=3 )
> typeset -A a=( [foo]=3 )
> typeset -A a=( )
>
> vq
>
