Robert Elz wrote in
<[email protected]>:
| Date: Sun, 16 Mar 2025 02:35:12 +0100
| From: Steffen Nurpmeso <[email protected]>
| Message-ID: <20250316013512.2aC3SIyk@steffen%sdaoden.eu>
|
|| The problem is not an empty field.
|
|Your problem might not be, but it all derives from that.
|
|| The problem is that ":a:" has to be splitted to ""+a by itself, not to
|| ""+a+"", as the second : only delimits the "a".
|
|Sure, and if that was the input, that would be what happens. But it
|isn't that ":a:" is an apparent internal implementation artifact, and
|what happens with that isn't specified anywhere.
|
|As I said in another message, I could explain (at least what happens
|in the NetBSD sh, not what happens in bash necessarily, that might be
|quite different) but I doubt it would help, and it certainly wouldn't
|be appropriate for bug-bash.
True. The only logical consequence, and here we come to the
message of Greg Wooledge, is
+ /* In order to be compatible with bash, NetBSD sh and
NetBSD ksh, at minimum, we need to
+ * deriviate from POSIX standardized behaviour, and
field split the quoted variant instead!
+ * This applies to $@ as well as $* */
+ if(*spcp->spc_ifs != '\0' &&
!su_cs_is_space(*spcp->spc_ifs)){
+ cp = n_var_vlook(n_star, TRU1);
+ goto jfs_split;
+ }
+
+ /* In all other cases individually field split the
expanded parameters */
and with that applied the test produces identical behaviour to all
of you, including bash.
|| But say, isn't ksh88 the template for POSIX,
|
|It was, but ksh88 is so seldom seen any more that its influence
|has waned.
|
|| and if so, is the above standard saying now ksh88 and all the
|| shells deviate,
|
|No, the standards writer noticed that shells did different things in
|this area, and as they couldn't convince everyone to change, they
|simply made the behaviour (semi-)unspecified (not really, as there
|aren't arbitrary choices allowed, just to drop an empty field or not).
|
|| or is the above one of those not "sooo" seldom
|| occasions where application behaviour was not hundred percent
|| correctly taken over to the initial standard document?
|
|I haven't looked back to see what the first SUS said about this
|(if I even have access to an early enough version), but that's
|ancient now, and no longer of any real relevance to anything.
|
|| In the latter case there should be an issue.
|
|Issue related to what? There are LOTS of places (in the shell, and
|elsewhere) where variant behaviour exists, and is documented as existing.
|
|Another (which happened to just come up in an entirely unrelated context,
|earlier this morning (here)) is that the pre and post decrement C arith
|operators aren't required to be implemented in $(( )) expansions. They
|can be, or they can be omitted. There are shells that do each.
|
|There's nothing odd here, except perhaps that the one standard is attemp\
|ting
|to both specify what users can expect to work in existing (conforming)
|implementations, and what new implementations should implement, and \
|sometimes
|can't quite work out which of those is more important.
|
|| This was, if i recall correctly, about the "empty fields *may* be
|| discarded".
|
|Yes.
|
|| And that is not the issue here.
|
|But it is, you've just ventured so far down the rabbit hole that you're
|not seeing that.
Yes, Robert, i do not see the relation. Maybe i am only too
tired.
|| at least real Spring is only three to four days ahead!!
|
|Here we have about a month to go before the middle of summer (or
|maybe the start of summer is in a few days, perhaps, the hottest
|period will be in about a month.) I doubt that will affect $*
|expansions though.
And unquoted $@.
--End of <[email protected]>
--steffen
|
|Der Kragenbaer, The moon bear,
|der holt sich munter he cheerfully and one by one
|einen nach dem anderen runter wa.ks himself off
|(By Robert Gernhardt)
