Re: doesn't bash do variable subst. or quote removal on function statement
Linda Walsh writes:
>> shopt -s expand_aliases; alias my=declare
>> declare fn=myfunc## function name in variable
> doesn't work
>> function $fn { echo $fn ; }
> -bash: `$fn': not a valid identifier
>>my -pf myfunc
> -bash: declare: myfunc: not found
>>
>> def="function $fn () { echo $fn ; }" ## but same statement, eval'd works
That's not the same statement. The same statement would be
def='function $fn () { echo $fn ; }'
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
implicit redirection of background within pipeline
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 -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall uname output: Linux treehug.home.kurahaupo.gen.nz 3.13.0-55-generic #94-Ubuntu SMP Thu Jun 18 00:27:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.3 Patch Level: 11 Release Status: release Description: The first backgrounded element within a pipeline component has its stdin redirected to /dev/null; this does not apply to the second and subsequent background elements. On a Linux system this can be observed with: echo x | ( ls -ld /proc/self/fd/0 & ls -ld /proc/self/fd/0 & wait ) On other systems it is apparent simply with: echo x | ( cat & wait ) # no output is produced Repeat-By: # this command produces no output: echo x | ( cat & wait ) Fix: # this is only a work-around: echo x ( :& cat & wait )
"read < <(:); echo $?" prints 0 when job control is disabled (should be 1?)
When job control is enabled: $ read < <(:); echo $? 1 When job control is disabled: $ read < <(:); echo $? 0 Is this a bug, or valid behavior? It seems to be caused by already_making_children being set in the bash without job control; the shell waits for a child and sets exec_status to 0 (the read builtin returns 1). I've reproduced this on both an x86_64 machine and in a MIPS VM, with both bash 4.3.42, and bash 4.4.0 (ie devel). Note that (with job control disabled) $ : | read; echo $? 1 and $ false < <(:); echo $? 0 or, $ false <(:); echo $? 0 while $ false; echo $? 1 (using a process substitution seems to trigger the behavior) Alastair Hughes
Re: implicit redirection of background within pipeline
hey, I am quite sure it happens here (devel branch, at 6f82653c5ef09aeeeba4376a1c65ce86c3605c00): execute_cmd.c +5115: if ((cmdflags & CMD_STDIN_REDIR) && pipe_in == NO_PIPE && (stdin_redirects (redirects) == 0)) async_redirect_stdin (); but after reading the comments some 3.5k lines earlier I am not sure how to fix it; of course commenting out the if in execute_cmd.c:5112-5115 solves it, but who can tell what it breaks? cheers, pg On Sun, Jan 10, 2016 at 8:23 AM, Martin D Kealey wrote: > > 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 -D_FORTIFY_SOURCE=2 > -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat > -Werror=format-security -Wall > uname output: Linux treehug.home.kurahaupo.gen.nz 3.13.0-55-generic > #94-Ubuntu SMP Thu Jun 18 00:27:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux > Machine Type: x86_64-pc-linux-gnu > > Bash Version: 4.3 > Patch Level: 11 > Release Status: release > > Description: > The first backgrounded element within a pipeline component has its > stdin redirected to /dev/null; this does not apply to the second and > subsequent background elements. > > On a Linux system this can be observed with: > echo x | ( ls -ld /proc/self/fd/0 & >ls -ld /proc/self/fd/0 & >wait ) > > On other systems it is apparent simply with: > echo x | ( cat & wait ) > # no output is produced > > Repeat-By: > # this command produces no output: > echo x | ( cat & wait ) > > Fix: > # this is only a work-around: > echo x ( :& cat & wait ) > >
Re: differences in Q.-removal, var-expansion and allowed characters in fn & var names
Andreas Schwab wrote:
That's not the same statement. The same statement would be
def='function $fn () { echo $fn ; }'
I know what you mean, but,
Yeah, sorta but I want it to do variable expansion AND quote removal.
I.e. using a var or DQ of the object-name, "a", works in declare.
Work ok:
> declare a=1 # OR
> declare "a"=1 and declare 'a'=1 # OR
> declare 'a=1' and declare "a=1" # OR
> x=a
> declare $x=1 # OR
> declare "$x"=1 and declare "$x=1"# All "work"
With eval, I can use:
> eval declare a=1,eval 'declare a=1' or eval "declare a=1"
> x=a &&
> eval declare $x=1eval 'declare $x=1' or eval "declare $x=1"
But w/functions, none of the 1st group will work
Vs. w/function, only
> eval 'function a { echo fna; }' # OR
> eval "function a { echo fna; }" # OR
> x=a # AND w/eval: only whole statements:
> eval 'function $x { echo fn$x; }' # OR
> eval "function $x { echo fn$x; }" # work.
None of the partial- or no- quote forms work.
While quoting rules for "Identifier Names" used w/"declare" are more
flexible/tolerant than those used for "functions", the *opposite*
is true for what characters are allowed in "function names" v.
"varnames". I.e names for functions allow UTF-8 but names
for variables do not. Using a name with a Greek alpha + a Roman '4':
> declare ɑⅣ=1 # doesn't work
-bash: declare: `ɑⅣ=1': not a valid identifier
> function ɑⅣ { echo fn_ɑⅣ; } # same name used for
func
> ɑⅣ
fn_ɑⅣ# UTF8 ok in fn-names
But this seems like it shouldn't work (number before the alpha):
> function Ⅳɑ { echo fn_Ⅳɑ; } # function "4a"
> Ⅳɑ
fn_Ⅳɑ
Even though the allowed characters for a "variable" Name are the
same as the characters allowed for "function" names. Why the
differences (in both cases?), also should a func starting with
a number be allowed in function names?
-l
