Sujet : Re: [ksh] Warning: pipe symbol within ${} should be quoted?
De : janis_papanagnou+ng (at) *nospam* hotmail.com (Janis Papanagnou)
Groupes : comp.unix.shellDate : 30. May 2025, 23:30:34
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <101dbii$n5nn$1@dont-email.me>
References : 1 2
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
On 30.05.2025 21:52, Martijn Dekker wrote:
Op 08-05-2025 om 00:00 schreef Janis Papanagnou:
With syntax-check ('ksh -n') I get a warning in Ksh for this expression
>
"${pipe#* | }"
>
concerning the pipe symbol. (Bash and Zsh don't complain.)
But bash and zsh don't offer linter functionality with -n at all, do they?
I don't know what they internally do when '-n' is provided, but the
man page (e.g. "man bash") says for the 'set' command (-n/-o noexec)
-n Read commands but do not execute them. This may be used
to check a shell script for syntax errors. This is ignored
by interactive shells.
which appears to be the same as what's written in the Ksh man page
(and in POSIX), and I suppose a similar thing valid for Zsh.
(2709)$ ksh -n -c '"${pipe#* | }"'
ksh: warning: line 1: | within ${} should be quoted
ksh -n currently produces the warning in this context for these characters:
& < > |
There is nothing in the POSIX shell grammar that suggests these should
be quoted there. The string between # and } is a shell pattern, and
those are not special characters in POSIX shell patterns.
While ksh does support extended shell pattern syntax in which & and |
may be metacharacters, those characters are not special unless that
extended shell pattern syntax is actually used (in which case you don't
want to quote them if you want them to be metacharacters). And < and >
are never special in patterns at all.
Yes, that would also be my view; actually reflecting the intention
of my post.
My conclusion is that this warning is unhelpful. I'll remove it.
Which appears to me to be the right thing to do.
By the way, a little test script shows that old ksh versions had some
bugs here:
pipe="one | two"
echo "${pipe#* | }"
pipe="one & two"
echo "${pipe#* & }"
pipe="one < two"
echo "${pipe#* < }"
pipe="one > two"
echo "${pipe#* > }"
Output on ksh 93u+ 2012-08-01, the last "stable" AT&T release:
| two
one & two
two
two
Output on ksh 93u+m as of 2022-02-08 (as well as AT&T ksh as of 93v-
2012-08-24 beta):
two
two
two
two
I believe the latter is the correct output.
(I'm not sure this is a question or just meant as an observation.)
At first glance I'd certainly agree. - My reluctance is only because
I've not thoroughly examined the behavior; at the moment I haven't
thought (e.g.) about any [syntactical] consequences of the BRE or ERE
syntax options that Ksh provides. - But as with Ksh regexps, say,
@(...|...), a BRE/ERE regexp will also have a syntactical context
that should determine whether in (e.g.) '${var#...}' meta-characters
in '...' need escaping or not. - Still, the same consequence applies
that you stated above ("no escapes if intended as meta-characters"),
so I think it's fine as you see that and put that.
Janis