Re: here strings fold newlines on MacOS
On 1/30/21 5:44 PM, Rich Lafferty wrote:
Bash Version: 5.1
Patch Level: 0
Release Status: release
Description:
Here strings ('<<<') fold newlines into spaces on MacOS, but not on Linux,
leading to incompatibilites in bash code expected to work the same on both
platforms.
This was fixed quite a while back, but still after Apple froze its version
of bash at 3.2.57. Maybe you should file a bug report with Apple.
(Just kidding, they don't care.)
--
``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: Are these bash.v.posix diffs still useful? They _seem_ dated...
On 1/30/21 6:50 PM, L A Walsh wrote: Since this "https://tiswww.case.edu/php/chet/bash/POSIX"; doesn't seem to be version specific, I'm assuming these are in the latest bash version. I don't understand the benefit of the differences involving hashed-commands and recovery behavior. It seemed like these behaviors may have served a purpose at one time, but now seem more likely to create an unnecessary failure case. First behavior: How is it beneficial for bash to store a non-executable in the command-hash? Probably not very, but it's not all that harmful. The `checkhash' option overrides this. What's really wasteful is to put something non-executable in the hash table when `checkhash' is set, only to remove it the next time you try to execute it. I changed that a few weeks back. And second, related behavior: Not searching for an alternative in the PATH if the old hashed value stops working. Again, `checkhash' covers this. -- ``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: here strings fold newlines on MacOS
Ah, yep — sorry for the false positive. I *have* 5.1.0 installed (and bashbug
picked that up!) but the context in which I encountered the bug was indeed
Apple’s ancient version. I could’ve sworn I tested it in both, but clearly
messed that up - verified it’s fixed in 5.1.0.
-Rich
On Jan 31, 2021, 1:35 PM -0500, Chet Ramey , wrote:
> On 1/30/21 5:44 PM, Rich Lafferty wrote:
>
> > Bash Version: 5.1
> > Patch Level: 0
> > Release Status: release
> >
> > Description:
> > Here strings ('<<<') fold newlines into spaces on MacOS, but not on Linux,
> > leading to incompatibilites in bash code expected to work the same on both
> > platforms.
>
> This was fixed quite a while back, but still after Apple froze its version
> of bash at 3.2.57. Maybe you should file a bug report with Apple.
> (Just kidding, they don't care.)
>
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
> ``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
Ordering bug when handling redirection with file descriptors
Hi! I have the below test case which works with dash, zsh, and has been
reported to work at least up to bash 4.4.12. After 4.4.23 it definitely
no longer works (I have also tested with 5.1.4).
#!/bin/sh
fn() {
echo a >&3
}
b=`fn 3>&1 1>&4 4>&-` 4>&1
With dash, it will simply exit silently (and `b` will be set to "a"),
but with current bash it errors out with the following error message:
test: line 10: 4: Bad file descriptor
This test case was taken from a real world example,
https://github.com/skarnet/skalibs/blob/f2c9b3cb899555af1a295df7341afc1cf55f7c71/configure#L322
While exploring similar issues, I found that
fn() {
echo a >&3
}
echo `fn 3>&1 1>&4 4>&-` 4>&1
also fails, but in this case dash doesn't seem to get it correct either.
I can provide straces for these, if necessary. This is all on Linux.
Thanks,
Érico
a few bugs, i hope you can read it
( http://ix.io/2NUp ) - sadly i dont have the depaster ready, some loop
deep logic faukts
bash-5.1# n=1 bash paster $( < thefiles )
++ paste BEGIN ++
++ paste BEGINFILE theintro
hello to this bug report, consisted as one big text file of pastes of
contents of files, with the code of 'depaste' back together-able
the tree ( ~/ixz/ ) is for short codings, it consists of the code files
with the bugs or fixed however outpointed topics by 'bug.' or 'success.'
name containing files
to explain the ixz codes, ixz, short x, long story, .. is now current name
here to short codibgs
aixz == add_ixz
an ixz is either a code file to be bound as alias ( the content of the file
as alias ) or marked for code eval later as keywords in associative arrays
./+ixz == addment of the files / dirs
./+kw == addment of keywords
./KWS == init KWS array
./ixz == the main init script to run or source
serval '.' '..' ~ and = marked helper or config files also
please let me know how you found that multiline paste
++ paste ENDFILE theintro ( 18 lined 158 worded 806 chared )
++ paste BEGINFILE thebugs
the bugs i came across affect the reuse code system of bash, i havent
looked at any .c sources much cause thatd be poitless as with my not
knowing of .c
so i invented simply ( in the sake of public domain open source better-up
systems ) singular short code files for parts of the acting of a script \
system .. then using em inside shortly also and voila , perfect code would
be
.. nearly was so, bash bugs came across
it came first with some here not documented 'unexpected token: <..>' errors
when aliasing conplex code
then now one hangs bash, before it didnt ( on initial 5 releases ) but it
didnt work i just say here it hangs bash till c-c
the others are
i set aixz=( .. .. ) and then source a file that binds them to aliases or
keywords, and as second i do redefine aixz=( ) and that other
value is just not.. the older two values it ran with, no idea ..
i had only once success, with an invalid combination like 'source all files
in the right order manually written' instead of with a second run, that
failed due to save bugs
..
bug.varnotnewalias bug.varnotnewalias.2 bug.varnotnewstillalias
bug.hangalias
++ paste ENDFILE thebugs ( 17 lined 209 worded 1119 chared )
++ paste BEGINFILE thefiles
theintro thebugs thefiles
if.bash.correctly.updated
paster
bug.varnotnewalias ixz.bug.varnotnewalias ixz.bug.varnotnewalias.o
bug.varnotnewalias.2 ixz.bug.varnotnewalias.2 ixz.bug.varnotnewalias.2.o
bug.varnotnewstillalias ixz.bug.varnotnewstillalias
ixz.bug.varnotnewstillalias.o
bug.hangalias ixz.bug.hangalias ixz.bug.hangalias.o
success.KWSran ixz.success.KWSran ixz.success.KWSran.o
featurereq.recursivealiases
bug.newaliasesnotavailabletillnewline
bug.aliasnotavailable
ixz
+ixz
+kw
KWS
IA.
IA..
IA=.
IA=..
IA~.
IA~..
ekw
ifkwe
ifkweo
kweval
kwp
++ paste ENDFILE thefiles ( 33 lined 38 worded 526 chared )
++ paste BEGINFILE if.bash.correctly.updated
i downloaded the you said and commented first the two ifs and endifs then
uncommented and changed 0 to 1, still no bug fixed, at least of my current
tree
i built using ./configure ; make -j 8 ; make install ; mv
/bin/bash{,.old..} ; cp /usr/local/bin/bash /bin
it says :
bash-5.1# bash --version
GNU bash, version 5.1.4(1)-maint (x86_64-pc-linux-gnu)
Copyright (C) 2020 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
hope thats correct
++ paste ENDFILE if.bash.correctly.updated ( 14 lined 100 worded 609 chared
)
++ paste BEGINFILE paster
#!/bin/bash
#shopt -s expand_aliases
{ paster=$( < /dev/fd/0 )
} <<'eo'
#!/usr/bin/gawk -f
# paste multiple files to one flat text file
BEGIN { ORS = OFS = "" ; dis[""] dis[0] dis["off"] dis["dis"]
dis["disable"] dis["disabled"] }
function header() { if ( ! ( n in dis ) ) print "++ paste BEGINFILE "
FILENAME " \0\n\n" }
function footer() { if ( ! ( n in dis ) ) print "\n\n++ paste ENDFILE "
FILENAME " \0( " statf() " )\n\n" }
function statf() { wl += FNR ; return FNR " lined " w " worded " c "
chared" }
END { if ( ! ( n in dis ) ) print "++ paste END ++ " file " files " wl "
lines " ww " words " wc " chars\n\n" }
BEGINFILE { ++file ; header() }
ENDFILE { footer(); ww += w ; wc += c ; w = c = 0 }
BEGIN { if ( ! ( n in dis ) ) print "++ paste BEGIN ++\n\n" }
{
w += NF ; c += length()
print $0 RT ; fflush()
}
eo
{
if [[ -v p ]]
then case "$p" in
ix*) curl -F 'f:1=<-' ix.io ;;
0x0*) .. ;;
*) cat ;; #>>"${o:=/tmp/${RANDOM:0:3}${RANDOM:0:3}}" ;;
esac
else cat
fi
} < <(
for arg
do [[ ! -e $arg ]] && continue
if [[ -d $arg ]]
then args+=( "$arg"/** )
else args+=( "$arg" )
fi
done
gawk -v n="$n" -e "$paster" -- "${args[@]}" )
++ paste ENDFILE paster ( 48 lined 255 worded 1126 chared )
++ paste BEGINFILE bug.varnotnewalias
here i set
Re: Ordering bug when handling redirection with file descriptors
31 Ocak 2021 Pazar tarihinde Érico Nogueira yazdı:
>
> #!/bin/sh
>
> fn() {
> echo a >&3
> }
>
> b=`fn 3>&1 1>&4 4>&-` 4>&1
Not a bug, POSIX allows implementations to perform assignments before
redirections in this case. To guarantee `4>&1' is in effect while `b=`fn
3>&1 1>&4 4>&-`' is being expanded, you should do:
{ b=`fn 3>&1 1>&4 4>&-`; } 4>&1
> While exploring similar issues, I found that
>
> fn() {
> echo a >&3
> }
>
> echo `fn 3>&1 1>&4 4>&-` 4>&1
>
>
> also fails
>
Command substitutions are expanded before redirections are performed.
--
Oğuz
Re: Ordering bug when handling redirection with file descriptors
.. but, I'm not sure about this case: $ set -o posix $ a=`uname >&4` env 4>&1 bash: 4: Bad file descriptor a= -- Oğuz
Re: Are these bash.v.posix diffs still useful? They _seem_ dated...
On 2021/01/31 10:54, Chet Ramey wrote: On 1/30/21 6:50 PM, L A Walsh wrote: First behavior: How is it beneficial for bash to store a non-executable in the command-hash? Probably not very, but it's not all that harmful. The `checkhash' option overrides this. --- Does checkhash do anything other than correct these two cases where bash doesn't auto-correct an invalid entry in the hash of commands? Perhaps checkhash is no longer necessary either if bash removes the older functionality. Didn't think it was harmful other than being an opportunity to clean up something no longer needed. I believe one of the problems you listed with bash is that it was too big & slow. Surely eliminating unused/unneeded quirks would be a, albeit small, step in addressing that. Or are you arguing to keep cruft and unnecessary complexity where possible? ;^)
