Re: Inconsistent behaviour of +=() and existing array keys
On Fri, Nov 28, 2014 at 03:47:49PM -0500, Maarten Billemont wrote: least for the associative arrays case, because in the case of normal arrays, ksh93 does some pretty funny things: | dualbus@hp ~ % ksh93 -c 'a=(); a+=([0]=b); typeset -p a' | typeset -A a=([0]=b) # Ha! Now 'a' is an associative array... Associative is more "default" in ksh93 as in bash: a=([0]=4) typeset -p a gives in bash: declare -a a='([0]="4")' in ksh93: typeset -A a=([0]=4) An empty array (a=()) gives in ksh93: typeset -C a=() -C means Compound variable, which is something different. -Helmut -- Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
\c-handling in $'-strings
Hello
The bash-manual says:
Words of the form $'string' are treated specially. The word expands to
string, with backslash-escaped characters replaced as specified by the
ANSI C standard. Backslash escape sequences, if present, are decoded as
follows:
...
\cxa control-x character
Now when I run this:
{
echo $LINENO $'\h\ca\ek'
echo $LINENO $'\h\cA\ek'
echo $LINENO $'\h\cd\ek'
echo $LINENO $'\h\c\d\ek'
echo $LINENO $'\h\c|d\ek'
echo $LINENO $'\h\cI wonder about the lines 6, 7, 8: 6,7: all non-alnum-characters (here |
and <) are printed as 0x1c?
And line 8: Why is the output truncated after '\c '?
What I'd expect is:
6 \hthat is an ^ 0x40-operation on the character following the \c. Is there an
intention for bash's behaviour?
Version is: GNU bash, version 4.3.39(2)-release (i686-pc-cygwin).
-Helmut
Re: \c-handling in $'-strings
Am 31.08.2015, 15:17 Uhr,SCHRIEB Chet Ramey : Conversion to a control character is effected by ANDing with 0x1f, since the valid control character range is 0-0x1f. If you have something that's not a valid control character after being ANDed with 0x1f, you get undefined results. There is a table in http://pubs.opengroup.org/onlinepubs/9699919799/utilities/stty.html#tag_20_123 Do you refer to the table titled "Circumflex Control Characters in stty"? It states for example: ? Running: echo $'\c?' |od -a echo $'\c[\c\\c]\c^\c_\c?' |od -a bash prints: 000 us nl 002 000 esc fs c ] rs us us nl I'd expect: 000 del nl 002 000 esc fs gs rs us del nl Also the ] in the output seems wrong, looks it gets the \\ wrong, though ksh93 does this also. Not a serious issue ... -Helmut
Re: \c-handling in $'-strings
Am 02.09.2015, 14:19 Uhr,SCHRIEB Chet Ramey : echo $'\c?' |od -a echo $'\c[\c\\c]\c^\c_\c?' |od -a bash prints: 000 us nl 002 000 esc fs c ] rs us us nl I'd expect: 000 del nl 002 000 esc fs gs rs us del nl Also the ] in the output seems wrong, looks it gets the \\ wrong, though ksh93 does this also. The Posix standardization of $'...' requires that the character after the Where is that described? I could not find anything about $'...' in the posix-docs. `\c' honor backslash escaping. Since the character becomes \c\\, the subsequent `c' and `]' are literals. I assume this is only true for "to-be-escaped" characters, that is $ ` " \ like for ".."-strings? Of course only \ is of interest here. If that is true then the output of ksh93 for echo $'\c\d' |od -a -> 000 eot nl is wrong? It removes the \ every time. -Helmut
redirection inside a process-substitution
When doing redirection inside a sub-process to a descriptor that is redirected to a file the output of the subshell goes into the file. Now when the same descriptor is again redirected to another descriptor for this whole command-list, the output of the sub-process goes to the other descriptor. Except when the subshell is subject to process-substitution: In this case the outer redirection has no effect to the sub-process. Why is that? Example: rm -f tb.err exec 3>tb.err echo -- 1 -- (echo 1 1>&3) 3>&1 echo tb.err ... cat tb.err echo -- 2 - echo >(echo 2 1>&3) 3>&1 echo tb.err ... cat tb.err echo -- 3 - echo >(echo 3 1>&3) echo tb.err ... cat tb.err Only test 3 should print 3 into tb.err. bash and ksh93 also print into tb.err in test 2, which is inconsistent compared to case 1. What's so special about process-substitution regarding redirection? -Helmut
Re: redirection inside a process-substitution
Am 23.08.2016, 17:00 Uhr, schrieb Chet Ramey: It has to do when things are processed. Process substitution is not a command or a redirection: it is a word expansion that expands to a file name. Word expansions are performed before redirections. Sure: similar to command-substitution as mentioned by Pierre. Bash does it right, I was wrong. Now extending Pierre's example: exec 3>tb.err echo 3>&1 > >(echo 1 1>&3) echo + cat tb.err echo - echo 3>&1 > >(echo 11 1>&3) echo + cat tb.err echo - echo > >(echo 2 1>&3) 3>&1 echo + echo - cat tb.err echo > >(echo 3 1>&3) echo + cat tb.err echo - wait I get in bash: 1 in ksh93 (where > >() does not work anyway, at least on cygwin): + - + - + - + - in zsh (sometimes, sometimes it prints nothing): + 1 - + 1 11 - - + - 1 11 2 + 1 11 2 3 - The zsh-output looks most reasonable to me: The sub-process redirects stdout to 3 which is connected to the file. So all sub-process-output gets appended to the file. The main-echo-output goes nowhere because the sub-echo does not read. I might be wrong again ;) Thanks, -Helmut
Re: redirection inside a process-substitution
Am 24.08.2016, 18:00 Uhr, schrieb Chet Ramey:
echo > >(echo 3 1>&3)
echo +
cat tb.err
echo -
wait
I get in bash:
Strange. I get
+
1
-
+
11
-
+
-
2
+
2
3
-
on Mac OS X and RHEL 6. I'm not sure why the last redirection (the one
with just process substitution and not 3>&1) doesn't cause the file to
be truncated, or the file pointer to be adjusted, but the trace is the
same in all cases.
I think because the redirection goes to a process, not a file.
in zsh (sometimes, sometimes it prints nothing):
I speculate that this has to do with something that zsh does to force
appending, whether that's lseek or something else, other than the fact
that zsh doesn't seem to use /dev/fd at all (I think it just straight
uses pipes). Bash doesn't do anything special with tb.err after opening
zsh uses temp-files for all process-substitution, which limits it's
features but is easier to do.
In my test bash got killed by SIGPIPE. Maybe you can reproduce it with:
#trap 'echo PIPE' PIPE
{ sleep 1; echo bla; } > >(echo r4 )
echo ---
When I uncomment the first line bash gets into real trouble:
obash bashbug.txt
bashbug.txt: line 3: echo: write error: Broken pipe
bashbug.txt: line 1: echo: write error: Broken pipe
bashbug.txt: line 1: echo: write error: Broken pipe
endlessly.
-Helmut
--
