Re: Arithmetic expansion in rediretion word is evaluated twice
On 6/2/20 1:18 AM, Oğuz wrote: > Below is the error message from the compilation failure after git pull && > make: You have to run configure again to remake the Makefiles. -- ``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: Seg fault on "echo ~nosuchuser"
On 6/1/20 7:58 PM, Ángel wrote: > On 2020-06-01 at 15:12 -0400, Chet Ramey wrote: >> I finally found a case where 16-byte alignment for memory returned by >> malloc() is required. But it's only on Linux systems that use systemd. >> I bet it's trying to marshal arguments for IPC and uses instructions >> that require 16-byte alignment. >> >> Thanks for your help verifying this. >> >> Chet > > You mean that with systemd getpwnam() crashes if using a malloc() that > returns addresses not 16-byte aligned? Yes, that's what I mean. The only significant change between the bash version that worked and the one(s) that did not is making the memory the bash malloc returns 16-byte aligned. Other systems not using glibc or systemd could not reproduce the issue. > Cornercase, surely, but it seems like a bug in whatever is assuming such > alignment. That's not even pointer-size alignment. If systemd or its support libraries are using copy instructions that require 16-byte alignment, though it's not documented, it's arguably not a bug. Chet -- ``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: Arithmetic expansion in rediretion word is evaluated twice
On 6/1/20 3:34 PM, Oğuz wrote: > See: > > $ unset foo > $ : <$((foo+=42)) > bash: 84: No such file or directory > $ echo $foo > 84 Yes. The redirection is evaluated once for the open and again for the error message. -- ``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: Arithmetic expansion in rediretion word is evaluated twice
Chet Ramey writes: > On 6/1/20 3:34 PM, Oguz wrote: >> See: >> >> $ unset foo >> $ : <$((foo+=42)) >> bash: 84: No such file or directory >> $ echo $foo >> 84 > > Yes. The redirection is evaluated once for the open and again for the > error message. That does seem rather a bug, or at least, a poor error message. Is it hard to save the string that was attempted to be opened? Dale
Re: local failure
Laurent Picquet writes: > Should the 'local' command be the one able to detect that the assignment to > the variable had an non-zero exit code and return the non-zero exit code? John Passaro writes: > I think the underlying question here is not exactly "how do I gather this > from the docs" as much as it is "how was I supposed to know about this and > act on it before I had to debug it?" >From where I stand, the situation appears differently. I knew that the the exit code from the command inside $( ... ) is ignored. So when someone complained that FOO=$( false) exits 1 but echo $( false ) exits 0, my reflex was that the first one was a bug. It was only when I went to the man page and read up did I discover to my surprise that the exit status of $( ... ) in standalone assignments is the exit status of the assignment. So my first answer is "You're supposed to know that the exit status of $( ... ) is discarded as it is a fundamental property of command substitution." Other than for the fact that it's only sometimes true... I would argue that "local" should not have any special behavior in regard to command substitution, as that would be Yet Another Special Case. Though it seems to me that one can get finer control over command substitution by doing: FOO="$( command1 )" # Test $? here to find out what command1 did. command2 $FOO # Test $? here to find out what command2 did. No doubt the special case for how command substitution exit statuses in standalone assignments are handled was done specifically to make this possible. Dale
Command substitution
Naively, I expect that FOO="$( command2 )" command1 $FOO has the same effect as command1 $( command2 ) and FOO="$( command2 )" command1 "$FOO" has the same effect as command1 "$( command2 )" Has anyone pushed the boundaries of this and can tell me whether there are gotchas? Dale
Re: Command substitution
On 6/2/20 9:44 PM, Dale R. Worley wrote: > Naively, I expect that > > FOO="$( command2 )" > command1 $FOO > > has the same effect as > > command1 $( command2 ) > > and > > FOO="$( command2 )" > command1 "$FOO" > > has the same effect as > > command1 "$( command2 )" > > Has anyone pushed the boundaries of this and can tell me whether there > are gotchas? What boundaries were you expecting? If this is related to the thread about the value of $? after command substitution in variable assignment vs. command arguments... that's already a gotcha according to many people. Despite being both documented and logical. Aside for that, obviously in one case you don't have a "FOO" variable in the shell environment, which does seem like a fairly major difference as it's a very common pattern for people to reuse the results of command substitution multiple times. Perhaps you meant to say "executes the same command process" instead of "has the same effect"? -- Eli Schwartz Arch Linux Bug Wrangler and Trusted User signature.asc Description: OpenPGP digital signature
Re: Command substitution
Quoting is useless when assigning variable from ouptut of command or another variable: $ foo=1 2 3 4 bash: 2: command not found Ok. But $ foo=$(seq 1 3) $ declare -p foo declare -- foo="1 2 3" $ foo="$(seq 1 3)" $ declare -p foo declare -- foo="1 2 3" No difference with or without double-quote. $ bar=$foo $ declare -p bar declare -- bar="1 2 3" $ bar="$foo" $ declare -p bar declare -- bar="1 2 3" Again, double-quoting is useless. But for commands: $ printf "<%s>\n" $foo <1> <2> <3> $ printf "<%s>\n" "$foo" <1 2 3> Same than $ printf "<%s>\n" $(seq 1 3) <1> <2> <3> $ printf "<%s>\n" "$(seq 1 3)" <1 2 3> Unfortunely, I don't retrieve this behaviour in man page. On Tue, Jun 02, 2020 at 09:44:45PM -0400, Dale R. Worley wrote: > Naively, I expect that > > FOO="$( command2 )" > command1 $FOO > > has the same effect as > > command1 $( command2 ) > > and > > FOO="$( command2 )" > command1 "$FOO" > > has the same effect as > > command1 "$( command2 )" > > Has anyone pushed the boundaries of this and can tell me whether there > are gotchas? > > Dale > -- Félix Hauri -- http://www.f-hauri.ch
