Re: Adding %n$ conversions to the printf utility (printf(1))

"Don Cragun via austin-group-l at The Open Group" wrote: > I think you're confusing the requirements for printf and echo. The standard > echo is not allowed to accept options. The standard printf does not define > any options, but allows them as implementation extensions. Thank you!

Re: Adding %n$ conversions to the printf utility (printf(1))

"Stephane Chazelas via austin-group-l at The Open Group" wrote: > 2021-09-10 22:46:26 +0100, Stephane Chazelas via austin-group-l at The Open > Group: > [...] > > I've personally used the feature to reorder items in sets, so > > would object to precluding reusing arguments. > [...] I agree...

Re: Adding %n$ conversions to the printf utility (printf(1))

"Stephane Chazelas via austin-group-l at The Open Group" wrote: > For the record, see the interesting discussions on the zsh > mailing list from when that feature was added there almost > exactly 20 years ago: > > https://www.zsh.org/mla/workers/2001/msg02715.html >From the information I

Re: Adding %n$ conversions to the printf utility (printf(1))

"Harald van Dijk via austin-group-l at The Open Group" wrote: > Either the distinction matters or it doesn't. If it matters, then it was > important to switch back to talk about what O?uz wrote. If it doesn't > matter, then it should not be a problem that I switched back to talk > about what

Re: Adding %n$ conversions to the printf utility (printf(1))

Harald van Dijk wrote: > > Not correct: ksh93 prints the same as bosh > > Indeed, something went wrong with the copying there. > > > and pleasew note that my example is > > using an integer format instead of a string format. > > Irrelevant. You wrote: > > > That is exactly what existing

Re: Adding %n$ conversions to the printf utility (printf(1))

"Robert Elz via austin-group-l at The Open Group" wrote: > Date:Fri, 10 Sep 2021 21:43:32 +0300 > From:=?UTF-8?B?T8SfdXo=?= > Message-ID: > > > | Wouldn't it be more useful if, in printf(1), `n' in `%n$' referred to the > | nth argument in the current set of

Re: Adding %n$ conversions to the printf utility (printf(1))

Harald van Dijk wrote: > No, it isn't. The second command prints > > ksh93: > >c a >d > > zsh: > >printf: 3: argument specifier out of range >c a > > bosh: > >c a > d Not correct: ksh93 prints the same as bosh and pleasew note that my example is using an integer

Re: Adding %n$ conversions to the printf utility (printf(1))

"O?uz via austin-group-l at The Open Group" wrote: > Wouldn't it be more useful if, in printf(1), `n' in `%n$' referred to the > nth argument in the current set of arguments being processed? For example, > the command: > > printf '%2$s %1$s\n' a b c d > > would print: > > b a > d

Re: [Issue 8 drafts 0001471]: Add an orthogonal interface for immediate macro expansion definitions to make

"David A. Wheeler via austin-group-l at The Open Group" wrote: > Allow me to *try* to bring this back to the original topic :-). > > I think it?s vital that ?::=?, as (provisionally) accepted *8* years ago, be > in the final version. > The underlying semantics of this (GNU make?s :=) are

Re: [Issue 8 drafts 0001471]: Add an orthogonal interface for immediate macro expansion definitions to make

"David A. Wheeler via austin-group-l at The Open Group" wrote: > This is easily disproven using the Linux kernel & LibreOffice as examples. > > The Linux kernel is large & uses GNU make. > Here?s the Linux main tree?s GitHub mirror: https://github.com/torvalds/linux > Main Makefile:

Re: [Issue 8 drafts 0001471]: Add an orthogonal interface for immediate macro expansion definitions to make

"David A. Wheeler via austin-group-l at The Open Group" wrote: > > > On Sep 8, 2021, at 1:06 PM, Joerg Schilling via austin-group-l at The Open > > Group wrote: > > Hasn't it been explained many times that the non-orthogonal behavior of > > gmake >

Re: [Issue 8 drafts 0001471]: Add an orthogonal interface for immediate macro expansion definitions to make

"Paul Smith via austin-group-l at The Open Group" wrote: > I asked for examples, or explanations of situations, where using the > POSIX ::= operator as currently defined isn't sufficient, and the > different behavior of the :::= operator is required instead. Hasn't it been explained many times

Re: [Issue 8 drafts 0001471]: Add an orthogonal interface for immediate macro expansion definitions to make

"David A. Wheeler" wrote: > > That as introduced by accident, because I did not realize at that time that > > gmake used an icompatible implementation that differs from smake and BSD > > make. > > That?s an unfortunate bug but easily fixed. It *is* specifically noted in the > Rationale :-).

Re: [Issue 8 drafts 0001471]: Add an orthogonal interface for immediate macro expansion definitions to make

"Paul Smith via austin-group-l at The Open Group" wrote: > On Wed, 2021-09-08 at 11:10 +0200, Joerg Schilling via austin-group-l > at The Open Group wrote: > > The :::= operator has been implemented in two independent make > > programs before it was standardized

Re: [Issue 8 drafts 0001471]: Add an orthogonal interface for immediate macro expansion definitions to make

"David A. Wheeler via austin-group-l at The Open Group" wrote: > I agree with Paul Smith. This was agreed on 8 years ago, and the widely-used > GNU make has > supported ::= as immediate expansion since 2013. That?s strong precedence. > See the discussion here: >

Re: shell: swapping var values in one command, plus some here doc stuff

"O?uz via austin-group-l at The Open Group" wrote: > Sorry for butting in, but according to the standard, is there really a > syntax error in the following? > > sh -c ': << do | for x in xxx > do > do echo $x > done' > > busybox sh, dash, gwsh, netbsd sh, and freebsd sh complain about a >

Re: [Issue 8 drafts 0001471]: Add an orthogonal interface for immediate macro expansion definitions to make

"Paul Smith via austin-group-l at The Open Group" wrote: > But here we're inventing an entirely new operator that NO VERSION of > make currently implements (yes, I understand that BSD make has a > different operator that works in this same way but that's not the same > thing: no existing

Re: $? in a simple command with no command name

Scott Lurndal wrote: > On Wed, Sep 01, 2021 at 10:59:46PM +0200, Joerg Schilling via austin-group-l > at The Open Group wrote: > > > > Something called SVR4.2 does not really exist. It was a minor change > > compared > > to SvR4 announced by Novell short before

Re: $? in a simple command with no command name

"Chet Ramey via austin-group-l at The Open Group" wrote: > Given the following: > > (exit 42) > a=$? b=`false` b=$? > > echo $? $a $b > > Bash prints 1 42 1. > > The original (v7) bourne shell and the rest of the research line through v9 > prints 1 1 (b is set to the empty string). That

Re: [1003.1(2016/18)/Issue7+TC2 0001437]: make: (document .NOTPARALLEL and .WAIT special targets) in RATIONALE

"Steffen Nurpmeso via austin-group-l at The Open Group" wrote: > Now it has to be said, GNU make supports an immense number of > special cases, pattern expansions etc., and this makes me wonder > whether the standard says anything to this. > Because, _if_ the standard would allow > > FOO =

Re: utilities and write errors

"Robert Elz via austin-group-l at The Open Group" wrote: > The bosh test is not useful though, since it doesn't bother to do > the required output at all ... > > bosh $ echo $PWD $OLDPWD > /tmp/b /tmp/a > bosh $ cd - > bosh $ echo $PWD $OLDPWD > /tmp/a /tmp/b Thank you for the hint, I

Re: sort -c/C and last-resort sorting

Robert Elz wrote: > Date:Mon, 05 Jul 2021 20:05:20 +0200 > From: "Joerg Schilling via austin-group-l at The Open Group" > > Message-ID: <20210705180520.kgbgk%sch...@schily.net> > > | That would be in conflict with long exi

Re: sort -c/C and last-resort sorting

"Geoff Clare via austin-group-l at The Open Group" wrote: > > If you like to disable -s, better use +s > > That wouldn't be suitable for standardisation as it doesn't follow > syntax guideline 4. The standard would need to use a different letter, > maybe -F for "fully sorted", or -l/-L for

Re: sort -c/C and last-resort sorting

"Robert Elz via austin-group-l at The Open Group" wrote: > Date:Mon, 05 Jul 2021 18:04:59 +0200 > From:"Joerg Schilling via austin-group-l at The Open Group" > > Message-ID: <20210705160459.e40cs%sch...@schily.net> > >

Re: sort -c/C and last-resort sorting

"Stephane Chazelas via austin-group-l at The Open Group" wrote: > That's even more justification for adding -s to the standard > though so people can at least choose to get a stable sort > portably. -S could probably be added as well, but I don't think > it wise to make the default behaviour

Re: sort -c/C and last-resort sorting

"Geoff Clare via austin-group-l at The Open Group" wrote: > > No, I was referring to /usr/xpg4/bin/sort > > That no longer exists in Solaris. If Illumos still has it they > should probably remove it (or make it a symlink to /usr/bin/sort). OK, I checked the source and the only difference

Re: sort -c/C and last-resort sorting

Stephane Chazelas wrote: > 2021-07-02 14:07:17 +0200, Joerg Schilling via austin-group-l at The Open > Group: > > "Stephane Chazelas via austin-group-l at The Open Group" > > wrote: > > > > > Is: > > > > > > printf '%s

Re: sort -c/C and last-resort sorting

"Stephane Chazelas via austin-group-l at The Open Group" wrote: > Is: > > printf '%s\n' a,b a,a | sort -c -t, -k1,1 > > Meant to succeed or not? > > It fails in GNU, busybox, OpenBSD, FreeBSD, Solaris, though with a > confusing: > > sort: -:2: disorder: a,a Try to use the POSIX sort

Re: utilities and write errors

"tg...@mirbsd.org via austin-group-l at The Open Group" wrote: > Don Cragun dixit: > > >No. > [?] > > Erm, yes. For some reason, I assumed the OP wrote &> instead of >& > which have the same meaning in GNU bash (but &> is the parse-trouble > one even if the bash manpage actively recommends

Re: utilities and write errors

"Robert Elz via austin-group-l at The Open Group" wrote: > Date:Mon, 28 Jun 2021 10:03:39 +0100 > From:"Geoff Clare via austin-group-l at The Open Group" > > Message-ID: <20210628090339.GA13976@localhost> > > | The (builtin) pwd utility got an error when it

Today is the 80th anniversary of the computer

Hi all, on May 12th 1941, Konrad Zuse presented his computer Z3 in the living room of his parents in Berlin-Kreuzberg. This was the first fully programmable computer. This computer did already use a floating point representation that is very close to the current IEEE floating poinnt numbers.

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Harald van Dijk wrote: > On 12/04/2021 12:47, (Joerg Schilling) wrote: > > Do you have a private variant og ksh93v? > > > > I get the same behavior from ksh88, the ksh93 from OpenSolaris and ksh93v. > > I don't. I was testing with ksh built from > <h

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

"Robert Elz via austin-group-l at The Open Group" wrote: > Date:Mon, 12 Apr 2021 15:07:28 + (UTC) > From:shwaresyst > Message-ID: <1662152200.1116623.1618240048...@mail.yahoo.com> > > | Then that is conformance bugs in those kernels, > > Rubbish. > > |

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Harald van Dijk wrote: > That is an implementation detail. As far as POSIX is concerned, there is > only a single command search when a command is executed, so "a > subsequent invocation" can only refer to the shell script attempting to > execute the same command again at a later time. POSIX

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Robert Elz wrote: > Actually, in my, and I suspect most, implementations, even the first > will invoke the "subsequent" clause, as the (parent) shell first searches > PATH to find the executable, and enters it in the hash table. Then it > forks, and the child repeats the whole thing (after

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

"shwaresyst via austin-group-l at The Open Group" wrote: > No, it's not nonsense. The definition of comment has all characters, > including '!', shall be ignored until newline or end-of-file being > conforming. Then tokenization which might discover an operator, keyword or > command

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

Harald van Dijk wrote: > >> If they are mistakes, they are widespread mistakes. As hinted in the > >> links, with PATH=/bin:/usr/bin, /bin/gcc and /usr/bin/gcc both existing > >> as files with execute permission, but /bin/gcc as a text file containing > >> #!/bad so that any attempt to execute

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

"shwaresyst via austin-group-l at The Open Group" wrote: > We are talking about the shell, not some bastardization of execve(), that > sees it's not a directly loadable process image so treats it as a script. For > those shells implementing shebang as an extension it is still them piping the

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

"shwaresyst via austin-group-l at The Open Group" wrote: > No, it's not nonsense. The definition of comment has all characters, > including '!', shall be ignored until newline or end-of-file being > conforming. Then tokenization which might discover an operator, keyword or > command

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

"Stephane Chazelas via austin-group-l at The Open Group" wrote: > 2021-04-10 22:12:47 +0200, Joerg Schilling via austin-group-l at The Open > Group: > > "Jan Hafer via austin-group-l at The Open Group" > > wrote: > > > > > For a sho

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

"Harald van Dijk via austin-group-l at The Open Group" wrote: > If they are mistakes, they are widespread mistakes. As hinted in the > links, with PATH=/bin:/usr/bin, /bin/gcc and /usr/bin/gcc both existing > as files with execute permission, but /bin/gcc as a text file containing > #!/bad

Re: [Shell Command Language][shortcomings of command utlity][improving robustness of POSIX shells]

"Jan Hafer via austin-group-l at The Open Group" wrote: > For a short recap why: There are `which, type, command, whence, where, > whereis, whatis, hash` used in shells. Worse, the semantics of `which` > is shell-dependent. which is a csh script and unrelated to Bourne or POSIX

Re: [1003.1(2016/18)/Issue7+TC2 0001454]: Conflict between "case" description and grammar

"Harald van Dijk via austin-group-l at The Open Group" wrote: > >> $ bosh -c 'case x in ( (x) echo match ;; esac' > >> bosh: syntax error at line 1: `(' unexpected > > > > It may be that you are missinterpreting the results. > > I'm not. You say there's no state change that happens as a

Re: [1003.1(2016/18)/Issue7+TC2 0001454]: Conflict between "case" description and grammar

"Harald van Dijk via austin-group-l at The Open Group" wrote: > On 21/02/2021 17:18, Joerg Schilling via austin-group-l at The Open > Group wrote: > > "Harald van Dijk via austin-group-l at The Open Group" > > wrote: > > > >> That is neit

Re: [1003.1(2016/18)/Issue7+TC2 0001454]: Conflict between "case" description and grammar

"Robert Elz via austin-group-l at The Open Group" wrote: > But I recall the original NetBSD sh code (and so probably original ash > code, though I haven't checked) which did this, which was (paraphrased) > while parsing the patterns (and their code) in a "case" statement > > if (token ==

Re: [1003.1(2016/18)/Issue7+TC2 0001454]: Conflict between "case" description and grammar

"Harald van Dijk via austin-group-l at The Open Group" wrote: > That is neither what the standard says nor what shells do, though. > >case x in ( (x) echo match ;; esac > > is rejected because that first '(' does change the parse state, making > the second '(' invalid. That state change

Re: [1003.1(2016/18)/Issue7+TC2 0001454]: Conflict between "case" description and grammar

"Robert Elz via austin-group-l at The Open Group" wrote: > The statement "case foo in (esac" is valid according to the grammar, > just as "case foo in esac" is. > > When the '(' was added, it was added (in shells) as a throw away token, > which changes nothing about the parse state, and is

Re: clarification needed: shell 'exec' + function (builtin, ???)

"Steffen Nurpmeso via austin-group-l at The Open Group" wrote: > Hallo Jörg, all, > > Joerg Schilling wrote in > <20201210004945.i3n8e%sch...@schily.net>: > |Steffen Nurpmeso wrote: > |> this is an iconv(3)-related error that was fixed in late

Re: clarification needed: shell 'exec' + function (builtin, ???)

Steffen Nurpmeso wrote: > this is an iconv(3)-related error that was fixed in later version > of the mailer you use. The very error came up on the ML this > year[1], basically you use LATIN1 on your box, as could be > expected, but Thorsten is known to be a Unicode character > "junkie", so to

Re: clarification needed: shell 'exec' + function (builtin, ???)

"Thorsten Glaser via austin-group-l at The Open Group" wrote: > This is because m4.opengroup.org runs qmail, the arsehole under the MTAs, > which auto-converted the mail from quoted-printable to 8bit, sending it > as 8bit even to MTAs that don't offer 8BITMIME (I configured my sendmail > not to

Re: clarification needed: shell 'exec' + function (builtin, ???)

"shwaresyst via austin-group-l at The Open Group" wrote: > > I agree more clarification is desirable. The reason I see as why the function > isn't executed is it may be treating it as an invoke of "sh -c ls", because > ls is a function, but this new sh does not inherit that definition so it

Re: [1003.1(2008)/Issue 7 0000513]: Add pattern rules (metarules) to make

"Robert Elz via austin-group-l at The Open Group" wrote: > Yes, I misinterpreted what you were trying to say, Paul Smith's subsequent > note (5156) made that obvious. I just wanted to make sure you understand why you did missinterpret the results from your test. > I'm not sure it really

Re: [1003.1(2016/18)/Issue7+TC2 0001418]: Add options to ulimit to match get/setrlimit()

Geoff Clare via austin-group-l at The Open Group wrote: > The ksh and bash behaviour of reporting multiple values seems more > useful to me, but I wouldn't object if others want to make this > unspecified. The bosh behavior is to permit more than one flag in case that there is no argument

Re: make pattern rules (was: Re: [Issue 8 drafts 0001325]: Allow make to remake an included file)

d like to do this, but I am of course not willing to have any potential incompatible changes from GNU make. > On Fri, 2020-11-06 at 13:25 +0100, Joerg Schilling wrote: > > > I'm not sure where the idea that pattern rules are immutable comes > > > from: in GNU make any patte

Re: make pattern rules (was: Re: [Issue 8 drafts 0001325]: Allow make to remake an included file)

Geoff Clare via austin-group-l at The Open Group wrote: > Paul Smith wrote, on 07 Nov 2020: > > > > Unless we are proposing pattern rules for inclusion in POSIX, [...] > > This was proposed in 2011 in bug 513, which is still open. the problem with this bug report is that I got the impression,

Re: [Issue 8 drafts 0001325]: Allow make to remake an included file

Paul Smith via austin-group-l at The Open Group wrote: > On Thu, 2020-11-05 at 19:36 +0100, Joerg Schilling wrote: > > .SUFFIXES: > > .SUFFIXES: .o .c > > .c.o: > > echo foo > > > > In other words, a users makefile has full control over the &

Re: [Issue 8 drafts 0001325]: Allow make to remake an included file

Paul Smith via austin-group-l at The Open Group wrote: > On Thu, 2020-11-05 at 09:25 +, Geoff Clare via austin-group-l at > The Open Group wrote: > > That doesn't make any difference, since .c and .o are both in the > > specified suffixes, so that brings the default .c.o rule into play. > >

Re: [Issue 8 drafts 0001325]: Allow make to remake an included file

Geoff Clare via austin-group-l at The Open Group wrote: > The make utility shall use one of the following two methods > to attempt to create the file or bring it up-to-date: > > 1. The "immediate remaking" method > > If make uses this method, any target rules or inference >

Re: [Issue 8 drafts 0001325]: Allow make to remake an included file

Geoff Clare via austin-group-l at The Open Group wrote: > > I wrote a blog post about this which may be interesting: > > http://make.mad-scientist.net/papers/advanced-auto-dependency-generation/ > > Having read this, I'm now wondering why we are bothering to add > requirements for generating

Re: make(1) parallelization, but especially .WAITing

Paul Smith via austin-group-l at The Open Group wrote: > On Tue, 2020-10-27 at 20:48 +0100, Steffen Nurpmeso wrote: > > |As for the idea of standardizing parallel builds, I'm all for it but it > > |will be a long process to work through the different implementations to > > |arrive at an

Re: make(1) parallelization, but especially .WAITing

Steffen Nurpmeso via austin-group-l at The Open Group wrote: > That old story of make incompatibilities and diversities calls up > one desire (i personally used inference rules only a short time in > general, otherwise only for very specific tasks, before and > thereafter i generated

Re: printf (the utility) expected range of integer values

Robert Elz wrote: > Date:Mon, 26 Oct 2020 15:02:26 +0100 > From: Joerg Schilling > Message-ID: > <5f96d6f2.jkFuBT5X4/F/wqwv%joerg.schill...@fokus.fraunhofer.de> > > | If the code you are using is from FreeBSD (Garret Damore) > > Wh

Re: printf (the utility) expected range of integer values

Robert Elz via austin-group-l at The Open Group wrote: > I should have included dash and yash in that list - their error messages > are very similar to what /usr/bin/printf on NetBSD prints (and the NetBSD sh, > which uses the same source code for its builtin printf), but when I looked >

Re: [1003.1(2016)/Issue7+TC2 0001138]: Add strsignal(), sig2str() and str2sig() to the standard.

Alan Coopersmith via austin-group-l at The Open Group wrote: > On 9/8/20 11:45 AM, Robert Elz wrote: > > I knew it was from the distant past. That it was AT corporate > > (the commercial computer people there, back then) that made a dumb > > decision is no surprise, they made so many... > >

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

Wojtek Lerch via austin-group-l at The Open Group wrote: > A structure member can be a "flexible array" in standard C, but that's not > the same thing as a VLA. Are you speaking about array[] in contrast to array[size] with size being a variable? Jörg -- EMail:jo...@schily.net

Re: [1003.1(2013)/Issue7+TC1 0000697]: Adding of a getdirentries() function

Steffen Nurpmeso via austin-group-l at The Open Group wrote: > I personally would say that these should be skipped. The data is > copied over to user buffers, and these entries are simply not > copied. That seems to be the best. The Group does not seem to > want to add DT_WHITEOUT or similar

Re: [1003.1(2016)/Issue7+TC2 0001392]: find(1): clarify whether -perm ops - and + should follow chmod

Geoff Clare via austin-group-l at The Open Group wrote: > I think I would prefer just to require consistency with chmod in Issue 8. > The difference from chmod violates the principle of least surprise. > > Another reason to disallow ignoring the umask for '=' without a "who" > is that this

Re: Pseudoterminal terminology in POSIX

Larry Dwyer via austin-group-l at The Open Group wrote: > How about the "control" side and the "terminal" side (of the paired > device files)? The Solaris man pty page since a really long time has this: By default, 48 pseudo-terminal pairs are configured as follows:

Re: Status of $'...' addition (was: ksh93 job control behaviour)

Steffen Nurpmeso wrote: > And for that it would be tremendous if $'' would be defined so > that it can be used as the sole quoting mechanism, and that would > then also include expansion of $VAR (i use \$VAR or \${VAR} in my > mailer). But to know exactly how problematic splitting of quotes >

Re: ksh93 job control behaviour [was: Draft suggestion: Job control and subshells]

Geoff Clare wrote: > It's only easy because (most/all?) shells take the easy option and do > a lexical analysis of the command to be substituted. Applications can't > expect the following to work, but if the feature was implemented > "properly", it would: > > showalltraps() { trap -p; } >

Re: Is ksh93's default alias command='command ' POSIX compliant?

Martijn Dekker wrote: > Op 18-06-20 om 14:11 schreef Joerg Schilling: > > Is my impression correct that you did not use the modifications from Redhat > > people that introduced non-portability, many bugs and a slowdown? > > Yes. This is really good news. > I don'

Re: Is ksh93's default alias command='command ' POSIX compliant?

Martijn Dekker wrote: > Op 16-06-20 om 17:37 schreef Alan Coopersmith: > > We are maintaining ksh93 packages, but not doing active development work on > > them. Our packages are still based on the last stable release from AT - > > 2012-08-01 with an unfortunately high number of local patches

Re: [1003.1(2016)/Issue7+TC2 0001345]: date(1) default format

Geoff Clare wrote: > I believe that leaving the default format unspecified, except for the > POSIX locale, was intentional. The same approach was taken for many > other utilities whose behaviour is affected by locale settings. I guess that there are too many languages, that differ from the

Re: sh: aliases in command substitutions

Robert Elz wrote: > However, I understand that the text that is there has been there a > long time now - and some shells (just a couple) may be relying upon > that - though it is hard to justify, given that this exclusion doesn't > apply to $() recognition outside double quoted strings, so what

Re: sh: aliases in command substitutions

shwaresyst wrote: > I never said this was expected to be clean, or even easy to do, just that it > is plausible for the feature set desired. What mucks it up is things that > change how lexical elements are expected to be recognized; case conditions > should use someting like , with left

Re: sh: aliases in command substitutions

shwaresyst wrote: > No, you only lex up to the newline or EOF in the first pass, whether the > ending ')' or other context delimeter is found or not, because after the > newline may be an io_here body. This is the recognition phase that skips > aliases, and the grammar currently has no

Re: sh: aliases in command substitutions

shwaresyst wrote: > When you are evaluating substitutions, yes, expansion is required, but not on > the first pass recognizing them. This is the effect of, in Item 5, "The > characters found from the beginning of the substitution to its end, allowing > for any recursion necessary to recognize

Re: sh: aliases in command substitutions

Robert Elz wrote: > Date:Tue, 21 Apr 2020 12:04:37 +0200 > From: Joerg Schilling > Message-ID: > <5e9ec535.lvxbvnyglwkdwkgu%joerg.schill...@fokus.fraunhofer.de> > > | Maybe this was a miss interpretatioon. > > Perhaps, but more like

Re: aliases in command substitutions

"Schwarz, Konrad" wrote: > Note the "matching closing parentheses", which means _lexical_ matching, > i.e., counting the number of open and closing parentheses > in the source text. This is not possible. Shells that try to do that, fail to correctly impklement here documents inside $(..).

Re: sh: aliases in command substitutions

shwaresyst wrote: > No, those are attempts at speed optimizations; the description before the > numbered list of XCU 2.3 has line delimiting comes first as the logical model > to determine tokenizing mode. This is continued in list items 4. and 5., that > substitutions shall not occur during

Re: sh: aliases in command substitutions

Robert Elz wrote: > Joseph's message helps provide context, and it may be that now the > "historically shells have not done this" is nolonger true, and the > standard should revert to its earlier form. Maybe this was a miss interpretatioon. The historic Bourne Shell did not implement support

Re: sh: aliases in command substitutions

Robert Elz wrote: > (lines 74718-22, Issue 7 TC2 - 2018 edition) says ... > > The input characters within the quoted string that are also enclosed > between "$(" and the matching ')' shall not be affected by the > double-quotes, but rather shall define that command whose output >

Re: pwd(1) pwd -L and multple adjacent slashes in $PWD,

Geoff Clare wrote: > Joerg Schilling wrote, on 14 Apr 2020: > > > > Geoff Clare wrote: > > > > > casper@oracle.com wrote, on 14 Apr 2020: > > > > > > (cd /home/casper; PWD=/home///casper pwd -L) > > > > /h

Re: pwd(1) pwd -L and multple adjacent slashes in $PWD,

Geoff Clare wrote: > casper@oracle.com wrote, on 14 Apr 2020: > > (cd /home/casper; PWD=/home///casper pwd -L) > > /home///casper > > > > > > Is this a correct implmentation? > > Yes. I know of no shell that behaves this way. Jörg -- EMail:jo...@schily.net

Re: sed '\n\nnd'

O?uz wrote: > > Given that implementations differ, we should probably make the > > behaviour explicitly unspecified. > > But this might be a bug in GNU's implementation. Why should a behavior that is aligned with the classical UNIX behavior (Solaris) be buggy? Jörg --

Re: sed '\n\nnd'

Geoff Clare wrote: > Solaris and HP-UX output "n" the same as GNU sed. Sou you verified what I assumed from the fact that Solaris, AIX and HP-UX are based on a common source from the i18n project. Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin

Re: sed '\n\nnd'

shwaresyst wrote: > The GNU version is more correct, in my opinion, in that the use of n as a > delimiter should take precedence over its use as control character alias with > the wording as is. The other versions appear to consider the BRE as > so does not match 'n'. The Solaris sed

Re: XCU: 'exit' trap condition

Dirk Fieldhouse wrote: > On 15/03/20 16:43, Harald van Dijk wrote: > >...> > > > "Before the shell terminates" is not limited to "before the top level > > shell terminates". If a shell terminates, even if it is a subshell that > > terminates, any EXIT trap action should be run. > > Sure, that

Re: XCU: 'exit' trap condition [was:Re: XCU: 'return' from subshell]

Dirk Fieldhouse wrote: > On 15/03/20 07:26, Robert Elz wrote: > >...> > >[I wrote:]>| Is there any suggestion that the 'exit'-like > behaviour of any shell that > >| implements it for 'return' in such contexts is subtly different from > > 'exit'? > > > > Not that I am aware of. exit

Re: Weird possibility with async processes, $!, and long running scripts

Robert Elz wrote: > Date:Sun, 15 Mar 2020 11:39:27 + (UTC) > From:shwaresyst > Message-ID: <1641208969.3419054.1584272367...@mail.yahoo.com> > > | For that purpose both still running processes and zombie processes have > | to be considered as active where

Re: Weird possibility with async processes, $!, and long running scripts

Robert Elz wrote: > Consider > > bg-process-1 & PID1=$! > long-running-monster-fg-process > bg-process-2 & PID2=$! > > "long-running-monster-fg-orocess" is something like a complete system > build, including lots of add-on utilities (imagine, gnome and all that > goes with it,

Re: XCU: 'return' from subshell

Robert Elz wrote: > I was referring to "in the standard". The standard is not static, > things are added (or move from unspecified to specified) as the > implementations converge upon some common definition for something new > or previously unspecified, and things are deleted when they become

Re: XCU: 'return' from subshell

Dirk Fieldhouse wrote: > You're reading too much into "If". I think it's clear that design > decisions from several decades ago take precedence, regardless of what > anyone would prefer. Eg > > where apparently the case

Re: XCU: 'return' from subshell

Chet Ramey wrote: > I use Mac OS X. I test on Linux. > > By far, the biggest difference between older Mac OS X/Linux and current Mac > OS X is using lldb instead of gdb for debugging. OK, I develop on Solaris and like dbx in favor of gxb at al. but it seems to be a pity that the Solaris

Re: XCU: 'return' from subshell

Don Cragun wrote: > Would this issue be resolved if we change the last sentence of the > description section of the return Special Built-In Utility from: > If the shell is not currently executing a function > or dot script, the results are unspecified. > to: > If the shell is

Re: XCU: 'return' from subshell

Chet Ramey wrote: > On 3/11/20 11:46 AM, Joerg Schilling wrote: > > > Since you most likely develop on Linux > > I don't; don't make assumptions. Interesting, where do you develop? Jörg -- EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berli

Re: XCU: 'return' from subshell

Chet Ramey wrote: > > I don't see that we should do this, but id you like to be able to reably > > get a > > > > ``NOEXEC'' or ``NOTFOUND'' > > > > from expanding "$/", there is a need for interprocess communication unless > > you > > use vfork() for that specific command. > > What is

Re: XCU: 'return' from subshell

Chet Ramey wrote: > > and that "foo" and not > > "bar" should be printed in each case: > > > > f1() { > >   ( echo foo; return ) > >   echo bar > > } > > This implies some interprocess communication between the parent and child > that simply doesn't exist, and nothing in the standard indicates

Re: XCU: 'return' from subshell

Dirk Fieldhouse wrote: > As to "baffling semantics", I suggest that these are two examples where > 'return' is meaningful (and far from baffling) and that "foo" and not > "bar" should be printed in each case: > > f1() { >( echo foo; return ) >echo bar > } Dop yo know a single shell that

Re: Thinking a bit outside of/stepping back from the box

Robert Elz wrote: > Date:Tue, 10 Mar 2020 15:24:02 -0700 > From:Donn Terry > Message-ID: > > | (No, not csh... something closer to Bourne/ksh than that.) > > That you'd even mention csh as a possibility in a context like this > is mind boggling. csh is based

  1   2   3   4   5   >