"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!
"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...
"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
"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
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
"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
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
"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
"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
"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:
"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
>
"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
"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 :-).
"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
"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:
>
"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
>
"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
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
"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
"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 =
"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
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
"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
"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>
>
>
"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
"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
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
"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
"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
"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
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.
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
>
"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.
>
> |
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
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
"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
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
"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
"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
"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
"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
"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
"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
"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
"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 ==
"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
"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
"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 later version
> |> of the mailer you use. The
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
"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
"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
"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
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
Paul Smith via austin-group-l at The Open Group
wrote:
> Unless we are proposing pattern rules for inclusion in POSIX, which I
> personally would be in favor of since they are much more useful than
> suffix rules, perhaps we should move the discussion to a different
> list?
I would like to do
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,
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 "builtin"
> > default rules even without a
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.
>
>
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
>
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
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
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
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)
>
> Where it originated I don't know
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
>
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...
>
>
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
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
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
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:
68 matches
Mail list logo
