Re: Word splitting for $@ in variable assignment

25 Haziran 2021 Cuma tarihinde Nora Platiel yazdı: > > To me, "$@" expanding to multiple words would mean that: > > $ var="$@" foo > > for $# > 0, behaves the same as: > > $ var="$1" "${@:2}" foo > But it wouldn't make any sense. `foo' would be subjected to alias substitution even though it isn't

Re: Word splitting for $@ in variable assignment

On Fri, Jun 25, 2021 at 01:47:01AM +0200, Nora Platiel wrote: > To me, "$@" expanding to multiple words would mean that: > > $ var="$@" foo > > for $# > 0, behaves the same as: > > $ var="$1" "${@:2}" foo > > which is obviously not the case. "$@" expands like "$1 "$2" ... when used in most con

Re: Word splitting for $@ in variable assignment

I was also confused by the same statement. On 2021-06-24 10:20 Chet Ramey wrote: > > But 3.4 Shell Parameters is a bit confusing: "Word splitting is not > > performed, with the exception of "$@" as explained below." > > This means that "$@" expands to multiple words, even though double quotes > wo

Re: Latest push for command substitutions

On 6/24/21 5:44 AM, Koichi Murase wrote: Maybe this is not caused by the change of this time, but another related problem. When the nested command substitutions are incomplete, an error message of the (false) syntax error is printed before PS2. The command is still executed correctly after closin

Re: Latest push for command substitutions

On 6/24/21 5:18 AM, Koichi Murase wrote: Please run it through any tests or scripts you have so we can shake out any bugs early. I haven't thoroughly tested it, but I found with a quick trial that the parser state seems to remain broken in the new command line after a syntax error: Thanks for

Re: 'wait' in command group in pipeline fails to recognize child process

On 6/23/21 6:17 PM, Martin Jambon wrote: On 6/23/21 6:24 AM, Chet Ramey wrote: On 6/22/21 9:54 PM, Martin Jambon wrote: In the posix definition, a subshell - is not necessarily implemented as a separate process - belongs to a unique shell - is not a shell Why is it not "a shell?" Because '

Re: Word splitting for $@ in variable assignment

On 6/24/21 4:09 AM, Ilkka Virta wrote: But 3.4 Shell Parameters is a bit confusing: "Word splitting is not performed, with the exception of "$@" as explained below." This means that "$@" expands to multiple words, even though double quotes would usually inhibit that. -- ``The lyf so short,

Re: function def crash

Yes figured the hard way :) Thanx On Thu, Jun 24, 2021 at 1:51 PM Greg Wooledge wrote: > On Thu, Jun 24, 2021 at 09:48:59AM +0200, Phi Debian wrote: > > $ function echo { \echo the function version; \echo "$@"; } > > For the record, this isn't how you write a function that wraps a builtin. > Use

Re: function def crash

On Thu, Jun 24, 2021 at 09:48:59AM +0200, Phi Debian wrote: > $ function echo { \echo the function version; \echo "$@"; } For the record, this isn't how you write a function that wraps a builtin. Use the "builtin" command instead. echo() { printf 'echo() wrapper invoked.\n' builtin echo "$@"

Re: Word splitting for $@ in variable assignment

On Thu, Jun 24, 2021 at 05:52:47PM +1000, Alvin Seville wrote: > Hello! I want to understand why the following code doesn't produce any > error: > set -- "a b" "c" > a="$@" It doesn't produce an error because the designers of the shell tried to make it "user-friendly" by having it guess what you

Re: function def crash

Arghh! I knew it was a pilot error :) unset PROMPT_COMMAND fix it :) my PROMPT_COMMAND reference a function that do 'echo' and I should use "command echo" in the echo function not \echo. On Thu, Jun 24, 2021 at 10:51 AM Phi Debian wrote: > I discovered that > > $ type -ta word > > Would te

Re: Latest push for command substitutions

Maybe this is not caused by the change of this time, but another related problem. When the nested command substitutions are incomplete, an error message of the (false) syntax error is printed before PS2. The command is still executed correctly after closing the command substitutions. $ LANG=C ./ba

Re: Latest push for command substitutions

lol what the weird behavior On Thu, Jun 24, 2021, 11:19 Koichi Murase wrote: > > Please run it through any tests or scripts you have so we can shake out > any > > bugs early. > > I haven't thoroughly tested it, but I found with a quick trial that > the parser state seems to remain broken in the

Re: Latest push for command substitutions

> Please run it through any tests or scripts you have so we can shake out any > bugs early. I haven't thoroughly tested it, but I found with a quick trial that the parser state seems to remain broken in the new command line after a syntax error: $ ./bash --norc $ printf '[%s]\n' $(if) bash: synta

Re: function def crash

I discovered that $ type -ta word Would tell me what I wanted i.e all the defs of word :) On Thu, Jun 24, 2021 at 9:48 AM Phi Debian wrote: > Hi All, > > Dunno if this is a bug or pilot error, I bumped into this. > > > $ type echo > echo is a shell builtin > > $ function echo { \echo the fun

Re: Word splitting for $@ in variable assignment

On Thu, Jun 24, 2021 at 10:53 AM Alvin Seville wrote: > Hello! I want to understand why the following code doesn't produce any > error: > set -- "a b" "c" > a="$@" > ? I expected smth like: main.sh: line 2: b: command not found due to word > splitting according to documentation > < > https://www

Word splitting for $@ in variable assignment

Hello! I want to understand why the following code doesn't produce any error: set -- "a b" "c" a="$@" ? I expected smth like: main.sh: line 2: b: command not found due to word splitting according to documentation .

function def crash

Hi All, Dunno if this is a bug or pilot error, I bumped into this. $ type echo echo is a shell builtin $ function echo { \echo the function version; \echo "$@"; } After this I got different behavior on 'same' OS version, same BASH version, meaning my environment must interact but can't tell to