Re: Wanted: quoted param expansion that expands to nothing if no params

[Lawrence Velázquez]

> On Mar 23, 2021, at 11:43 PM, Eli Schwartz  wrote:
> 
> On 3/23/21 11:24 PM, L A Walsh wrote:
>> Too often I end up having to write something like
>> if (($#)); then  "$@"
>> else   # = function or executable call
>> fi
>> 
>> It would be nice to have a expansion that preserves arg boundaries
>> but that expands to nothing when there are 0 parameters
>> (because whatever gets called still sees "" as a parameter)
>> 
>> So, example, something like:
>> 
>> $~ == "$@" #for 1 or more params
>> $~ ==  no param when 0 param, # so for the above if/else/endif
>> one could just use 1 line:
> 
> It's not clear to me, how you expect this to differ from the existing
> behavior of "$@" or "${arr[@]}" which already expands to 
> rather than an actual "" parameter.

The original message does recall the behavior of the earliest Bourne
shells [1][2], but that is surely not relevant here, given the use
of ((...)). Right? RIGHT???

  [1]: https://www.in-ulm.de/~mascheck/various/bourne_args/
  [2]: 
https://www.gnu.org/software/autoconf/manual/autoconf-2.70/html_node/Shell-Substitutions.html#index-_0022_0024_0040_0022

vq

Re: Wanted: quoted param expansion that expands to nothing if no params

[Eli Schwartz]

On 3/23/21 11:24 PM, L A Walsh wrote:
> Too often I end up having to write something like
> if (($#)); then  "$@"
> else   # = function or executable call
> fi
> 
> It would be nice to have a expansion that preserves arg boundaries
> but that expands to nothing when there are 0 parameters
> (because whatever gets called still sees "" as a parameter)
> 
> So, example, something like:
> 
> $~ == "$@" #for 1 or more params
> $~ ==  no param when 0 param, # so for the above if/else/endif
> one could just use 1 line:

It's not clear to me, how you expect this to differ from the existing
behavior of "$@" or "${arr[@]}" which already expands to 
rather than an actual "" parameter.

>    $~
> 
> My examples used ~, as I didn't think it was used anywhere.
> 
> I can't control how called programs will handle / deal with a
> present, but empty parameter, which is why I thought something that
> expands to nothing in the empty case would seem ideal.
> 
> Anyone else have a trivial solution for this problem?

Does "be mindblown when it worked as is to begin with" count?

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User



OpenPGP_signature
Description: OpenPGP digital signature

Wanted: quoted param expansion that expands to nothing if no params

[L A Walsh]

Too often I end up having to write something like
if (($#)); then  "$@"
else   # = function or executable call
fi

It would be nice to have a expansion that preserves arg boundaries
but that expands to nothing when there are 0 parameters
(because whatever gets called still sees "" as a parameter)

So, example, something like:

$~ == "$@" #for 1 or more params
$~ ==  no param when 0 param, # so for the above if/else/endif
one could just use 1 line:

   $~

My examples used ~, as I didn't think it was used anywhere.

I can't control how called programs will handle / deal with a
present, but empty parameter, which is why I thought something that
expands to nothing in the empty case would seem ideal.

Anyone else have a trivial solution for this problem?

Re: Redirection between assignment statement and command name prevents alias substitution

[Robert Elz]

Date:Tue, 23 Mar 2021 20:27:27 +0200
From:=?UTF-8?B?T8SfdXo=?= 
Message-ID:  


  | Apparently I couldn't make myself clear there,

Perhaps, or I was just failing to understand.   Never mind.
But this (as you know) was nothing like I imagined you meant.

  | # doesn't work anywhere
  | P1 P2B P3

At least in the NetBSD sh, as soon as the \n that comes from the
expanded P2B is seen, the shell switches to heredoc input reading,
which doesn't read tokens at all, just lines until the end delimiter
is seen.   There's absolutely no chance that any aliases can be found
in there ("P3" is yet to be read at that point - it simply becomes part
of the heredoc).

 | I thought it would keep fetching tokens until reaching one that can't
 | be an alias or is an alias but doesn't have a space at the end,
 | and then go back to the first expanded string and continue from there.

It might be possible to do it that way, I haven't really thought about
the implications (aside from duplicating all of the alias values, in the
alias table, and in the input stream), and certainly haven't tried it.
The current way is simpler, everything just kind of fits (the shell
already needs the mechanism to switch to reading from an internal
string, to handle eval, and traps, aliases use the same mechanism).
So, just stick the alias value into the input stream as a string, and
continue as if nothing happened (with the extra bookkeeping that
aliases require of course).

kre

Redirection between assignment statement and command name prevents alias substitution

[Oğuz]

On Tue, Mar 23, 2021 at 8:14 PM Robert Elz  wrote:

>   | (except aliases that
>   | appear in a place where only a here document body may appear, but no
> shell
>   | does that the way I think they'd do, so..)
>
> What do you expect there?   A here doc body comes after a newline after a
> here doc redirect operator - it certainly isn't in a command word position,
> and because of the newline cannot possibly be immediately after an alias
> expansion which requested more alias expansions (the newline would be in
> the way).  So, no alias expansion is possible.   Nor would any be wanted
> I'd expect, here docs are data not commands (though of course, any data
> can become commands if used appropriately ... if that were to happen then
> alias expansion would happen to the here doc contents when it is being
> parsed as a command string).


Apparently I couldn't make myself clear there, sorry. Here's a MRE:

alias P1='cat << EOF ' P2A='
foo
EOF
' P2B='
 ' P3='foo
EOF
'

# works fine everywhere except bash
P1 P2A
# doesn't work anywhere
P1 P2B P3

I expected both to work.


>
>   | I don't see the point in checking the syntax of the input in the
> middle of
>   | alias substitution,
>
> In the middle of the substitution, no, but that's not the issue.   Most
> shells (I think, but excluding bash for sure) use recursive descent
> parsers.
> Those fetch a token at a time, and sometimes look at the one following.
> Each time a token is fetched, the shell indicates whether a reserved word
> or alias is possible at this point (and if so, the tokeniser checks,
> returns
> the reserved word token if one is seen, or expands the alias and returns
> the first token from the expanded string) - unquoted spaces and tabs, aside
> from terminating word tokens, are ignored.  The shell then looks at the
> token
> to decide what should appear next (or if the token cannot occur in the
> current situation, generate a syntax error).


I thought it would keep fetching tokens until reaching one that can't be an
alias or is an alias but doesn't have a space at the end, and then go back
to the first expanded string and continue from there.


>
>
> In the example in question, the 'l' alias expands to '< ', the token there
> is '<' the redirect operator, the space indicates more alias expansion can
> follow, but otherwise is discarded.   The "redirect from" token is returned
> to the parser, it sees that and starts to parse the redirection, which
> means
> fetching the next token which will be the filename (even though we haven't
> seen the command word yet, reserved word lookups must be disabled, and
> normally
> alias expansion would be as well, if it weren't for that space in the 'l'
> alias).
>
> So, it isn't so much "checking the syntax" but that the syntax parse is
> happening in parallel with fetching tokens, and the two affect each other.
>
> kre
>



-- 
Oğuz

Re: Redirection between assignment statement and command name prevents alias substitution

[Robert Elz]

Date:Tue, 23 Mar 2021 14:51:02 +0300
From:=?UTF-8?B?T8SfdXo=?= 
Message-ID:  

  | (except aliases that
  | appear in a place where only a here document body may appear, but no shell
  | does that the way I think they'd do, so..)

What do you expect there?   A here doc body comes after a newline after a
here doc redirect operator - it certainly isn't in a command word position,
and because of the newline cannot possibly be immediately after an alias
expansion which requested more alias expansions (the newline would be in
the way).  So, no alias expansion is possible.   Nor would any be wanted
I'd expect, here docs are data not commands (though of course, any data
can become commands if used appropriately ... if that were to happen then
alias expansion would happen to the here doc contents when it is being
parsed as a command string).

  | I don't see the point in checking the syntax of the input in the middle of
  | alias substitution,

In the middle of the substitution, no, but that's not the issue.   Most
shells (I think, but excluding bash for sure) use recursive descent parsers.
Those fetch a token at a time, and sometimes look at the one following.
Each time a token is fetched, the shell indicates whether a reserved word
or alias is possible at this point (and if so, the tokeniser checks, returns
the reserved word token if one is seen, or expands the alias and returns
the first token from the expanded string) - unquoted spaces and tabs, aside
from terminating word tokens, are ignored.  The shell then looks at the token
to decide what should appear next (or if the token cannot occur in the
current situation, generate a syntax error).

In the example in question, the 'l' alias expands to '< ', the token there
is '<' the redirect operator, the space indicates more alias expansion can
follow, but otherwise is discarded.   The "redirect from" token is returned
to the parser, it sees that and starts to parse the redirection, which means
fetching the next token which will be the filename (even though we haven't
seen the command word yet, reserved word lookups must be disabled, and normally
alias expansion would be as well, if it weren't for that space in the 'l'
alias).

So, it isn't so much "checking the syntax" but that the syntax parse is
happening in parallel with fetching tokens, and the two affect each other.

kre

Re: Redirection between assignment statement and command name prevents alias substitution

[Oğuz]

On Tue, Mar 23, 2021 at 2:26 PM Robert Elz  wrote:

> though the NetBSD sh does expand it


dash and NetBSD sh do aliases just the way I expect (except aliases that
appear in a place where only a here document body may appear, but no shell
does that the way I think they'd do, so..), it's fascinating.


> after
> a '<' you're certainly not in the command word position, what comes next
> must be a redirect operand (filename).   The space at the end of the 'l'
> alias value should cause alias expansion, but I can almost understand why
> it might not.
>

I don't see the point in checking the syntax of the input in the middle of
alias substitution, but that might be because I have never attempted to
write a shell or anything that complex.


>
> kre
>
>

Re: Redirection between assignment statement and command name prevents alias substitution

[Robert Elz]

Date:Tue, 23 Mar 2021 13:10:19 +0300
From:=?UTF-8?B?T8SfdXo=?= 
Message-ID:  



  | $ echo a > a
  | $ echo b > b
  | $ alias l='< ' a=b
  | $ l a cat
  | a
  |
  | I can't think of any reason not to expand `a' there.

I can think of a reason (though the NetBSD sh does expand it) -- after
a '<' you're certainly not in the command word position, what comes next
must be a redirect operand (filename).   The space at the end of the 'l'
alias value should cause alias expansion, but I can almost understand why
it might not.

kre

Re: Redirection between assignment statement and command name prevents alias substitution

[Oğuz]

On Tue, Mar 23, 2021 at 11:01 AM Robert Elz  wrote:

> Kind of interesting that ksh93 seems to do the same thing.
>

Yeah, I don't know, might be a coincidence. Another curious case where
ksh93 differs in behavior from all other shells I have is this:

$ echo a > a
$ echo b > b
$ alias l='< ' a=b
$ l a cat
a

I can't think of any reason not to expand `a' there.

Re: missing way to extract data out of data

[Andreas Schwab]

On Mär 22 2021, Dale R. Worley wrote:

> Greg Wooledge  writes:
>> Partly true.  seq(1) is a Linux thing, and was never part of any
>> tradition, until Linux people started doing it.
>
> Huh.  I started with Ultrix, and then SunOS, but don't remember learning
> seq at a later date.

According to , seq
appeared in Version 8 AT UNIX.

> I've never tracked down why, but the Perl executable is a lot smaller
> than the Bash executable.

Is it?

$ size /usr/bin/perl /bin/bash
   textdata bss dec hex filename
2068661   27364 648 2096673  1ffe21 /usr/bin/perl
1056850   22188   61040 1140078  11656e /bin/bash

Of course, a lot of perl is part of loadable modules.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Redirection between assignment statement and command name prevents alias substitution

[Robert Elz]

Date:Tue, 23 Mar 2021 08:43:54 +0200
From:=?UTF-8?B?T8SfdXo=?= 
Message-ID:  


  | $ a=b >&2 u
  | No command u found, did you mean:

Kind of interesting that ksh93 seems to do the same thing.   No other
shell I was able to test however (including ancient pdksh and mksh).
(except old NetBSD sh, with broken aliases, where none of the three forms
worked).

kre

Redirection between assignment statement and command name prevents alias substitution

[Oğuz]

$ alias u=uname
$ >&2 a=b u
Linux
$ >&2 u
Linux
$ a=b >&2 u
No command u found, did you mean:
...

In all three cases `u' is in a position where a command name may appear,
and should be subjected to alias substitution.

This is reproducible on devel too


-- 
Oğuz