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

[Joerg Schilling via austin-group-l at The Open Group]

"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!

Indeed, my own implementation even supports "printf -help".

So the main problem I see is that the option -r is probably not usable anymore
because ksh's builtin print(1) implements -r for a different purpose.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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...
 
> As mentioned on that mailing list and it's still undocumented,
> -r can be used with print -f to disable reuse:

The problem, POSIX defines printf(1) to not handle options. So I don't think, 
we could add that.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 have, that feature (even though limited to string 
arguments) was introduced for /usr/bin/printf around 1988 for SVR4 or SunOS
(I am not sure about the origin). This is from before POSIX did introduce 
printf(1) and as a result, there is a difference from what POSIX requires 
for printf(1).

The important fact however is that it was intended for use with gettext(1).

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 O?uz wrote. It may be that the distinction doesn't matter. If 
> it helps with understanding, I will answer again based on the integer 
> version.
> 
> O?uz's suggested output, translated to the integer version, would be 
> (please correct me if I am misstating anything here):
> 
>$ printf '%3$d %1$d\n' 1 2 3 4
>0 1
>0 3

This is not correct, the correct output is:

printf '%3$d %1$d\n' 1 2 3 4
3 1
0 4

so please read the documentation, e.g. from:

http://schilytools.sourceforge.net/man/man1/bosh.1.html

play a bit with that feature and rethink what you wrote...

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

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 implementations do.

Well, I modified the example to make the result easier to understand, since 
the POSIX standard requires an empty string to be printed for a missing 
string argument and a 0 for a missing integer argument.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 arguments being processed?
> 
> That's what it does in current implementations.   And if for some bizarre
> reason it was useful to add a facility to do:
> 
>   | printf '%2$s %1$s\n' a b c d
> 
> when one can just as easily do
> 
>   printf '%s %s\n' b a d c
> 
> then that is how it should be defined I suppose.
> 
> But that's not why it was added to printf(3) nor why it is probably going

Could you please give an example with printf(3) and the gettext(3) family that 
explains when you believe there is a problem?

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

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 format instead of a string format.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 c
> 
> And the command:
> 
> printf '%3$s %1$s\n' a b c d
> 
> would print:
> 
>  a
>  c
> 
> That is, the empty string would be taken for the third argument.

That is exactly what existing implementations do.

There is just a minor bug in the implementation found in zsh.

Zsh prints:

printf '%d %d\n' 1 2 3
1 2
3 0

but with %n$ it prints:

printf '%2$d %1$d\n' 1 2 3 
printf: 2: argument specifier out of range
2 1

while other implementations that support %n$ print:

printf '%2$d %1$d\n' 1 2 3
2 1
0 3

So zsh is self incompatible.

The "other" implementations are bosh, ksh93 and /bin/sh from FreeBSD.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"Paul Smith via austin-group-l at The Open Group" 
 wrote:

> On Thu, 2021-09-09 at 10:07 +0100, Geoff Clare via austin-group-l at
> The Open Group wrote:
> > You took a risk when you added ::= to gmake while it was only an
> > ccepted proposal, not part of an approved revision to the standard.
> > And gmake users who make use of it in the expectation that is will
> > be required by POSIX are taking a similar risk.
> 
> This is a fine position when POSIX is following it's normal charter
> which is to standardize existing behaviors that have been proven to be
> useful or at least widely used.
> 
> It's a problem when POSIX is inventing new syntax, like it is here.
> Especially if issues are only published every 10 years or more.

The problem is that we are talking about an invention from gmake that is only 
supported in gmake while other make implementations agreed on a different way 
that is better aligned with the original UNIX make features.

POSIX did not invent things but just defined new operator patterns for already
existing features. Let me repeat:

::= is based on a feature available only in gmake

:::=is based on a feature that was available by smake and BSD make

The := operator could not be used in POSIX because gmake and BSD make decided
to reuse an operator supported by SunPro Make since January 1986 but with 
completely different behavior.

Given that the intention of POSIX is not to make existing UNIX implementations
incompatible, a new operator pattern had to be introduced. If gmake had been 
more careful with defining a unique operator pattern for immediate expansion 
assignment in 1989, there was a big chance that even the operator pattern used 
by gmake could be used by POSIX.


Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 widely used.
> 
> I don?t know if adding :::= and +:= operators is that vital. But if adding 
> them
> (along with ::=) will yield a unified standard for ?make" that enables more 
> makefiles

The gmake := method is not aligned with the basic concept of make as it 
introduces a differen type of macro with properties that differ from normal 
make macros and that make the behavior of += non-predictable.

The :::= method, based on the := method from BSDmake/smake is a clean 
enhancement to the original UNIX make concept.

I already mentioned that I spent a lot of time to implement support for that 
::= in SunPo Make even tough that is not needed if you have :::= and +:=

It would be fair to see that in gmake soon, in order to get a better base for
portable makefiles. If that doesn't happen, I would get the impression that 
gmake is not interested in a common base of functionality, in special as the 
effort to implement that by a person with knowledge of gmake implementation 
details is 3-4 hours only.

> I think it?s somewhat situationally-dependent. If the directories are
> truly independent, recursive makefiles often forgo some parallelism but
> are otherwise fine. Once there are interdependencies, my experience
> mirrors Miller?s. In any case, it?s clear that a number of users of ?make?
> depend on immediate evaluation, so it is reasonable to standardize it.

The dominant problem with recursive makefiles is that there is no way to 
automatically relink a binary in case that one of the libraries has become 
more recent.

If you use SunPro Make and the SVr4 linker together with the .KEEP_STATE:
target, this problem has gone and there is no need for makefiles to be truly  
independent.

It is interesting to see that gcc did of course immediately add support for 
the SUNPRO_DEPENDENCIES environment that is used for automatic include 
dependencies since January 1986.

It is disappointing to see that 30 years after introducing the callback 
interface into the SVR4 linker (via the SGS_SUPPORT ** environment), there 
still is no support in gld.

**) See SunPro Make man page: 
http://schilytools.sourceforge.net/man/man1/make.1s.html

and the linker man page at: http://schillix.sourceforge.net/man/man1/ld.1.html

http://schillix.sourceforge.net/man/man3lib/libelf.3lib.html

On the other side, using LD_PRELOAD could allow to intercept open() calls and 
give SunPro Make a similar feature vewn with a less progressive linker, but I 
am reluctant to implement that unless there is a real user and there is no 
proof that the gld people are really unwilling to support the SGS_SUPPORT 
environment. 

After all, a limited set of pattern rules, see

https://www.austingroupbugs.net/view.php?id=519

is of course more important. If we agree on the subset I did propose (I could 
rewrite that in a more compact form), we did have the minimum set of features 
for portable makefiles for the 21th century in POSIX make.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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: https://github.com/torvalds/linux/blob/master/Makefile 
> 
> And see also its scripts/Makefile.*
> It uses immediate-evaluation ?:=? & includes.

Life without a pug is possible, but pointless. (Loriot)

I am not saying it is impossible, but it hurts and is extremely hard to 
maintain because of the unpredictable behavior of the += operator if _some_ of 
the make macros have been created via the gmake := operator. The Linux folks 
are using the gmake := operator just because there currently is no better 
alternative in gmake.
 
If gmake did implement support for the :::= and +:= operator and properly 
document that feature, we would need to wait 10 years to judge. I am shure 
that the Linux kernel makefiles will be converted to the better (because it 
works in a predictable way) method.

As said before, I wish we did not have introduced ::= before and rather 
directly icluded the smake/BSD make method. On the other side, BSD introduced 
the modification to not expand $$ approx. 3 years ago and that was after we 
did introduce ::=.

After all, UNIX did evolve and constantly learn from the past, this is just 
one example.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 
> > for the += operator for macros created with the gmake := operator is a 
> > source 
> > of unpredictable behavior, in special if large layered (via include) 
> > makefile
> > systems are used and you cannot easily see how a macro was initially 
> > created?
> 
> It has been claimed in https://www.austingroupbugs.net/view.php?id=1471 
> <https://www.austingroupbugs.net/view.php?id=1471> ,
> but not proven. I believe the number of users of GNU make dwarfs all
> other make implementations combined, and this hasn?t been a problem for users 
> of GNU make.
> I?ve never seen that claim by actual users of GNU make. Nor has Paul Smith, 
> maintainer of GNU make.

Users of smake and BSD make write large and structured makefiles that use 
plenty of include statements. This does not apply to gmake users and may be 
the reason why gmake users do not complain.

Please note that the reason why gmake has many users is not caused by it's 
features but by the fact that there are OS distributions that install gmake 
under the name "make".

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 that the non-orthogonal behavior of gmake 
for the += operator for macros created with the gmake := operator is a source 
of unpredictable behavior, in special if large layered (via include) makefile
systems are used and you cannot easily see how a macro was initially created?

The :::= operator fixes this and allows to predict how other operators behave.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 :-).

Really? How do you like to fix that incompatible gmake behavior?
 
> A person named ?joerg? in this bug report noted this semantic difference in 
> 2011-11-17 in our discussion on this topic:
> https://www.austingroupbugs.net/view.php?id=330 
> 
> I take it you?re not the same person? Or maybe you knew this at one time & 
> forgot it later?
> If you forgot it later, no big deal, forgetting happens to all of us :-).

Please carefully read the SunPro Make man page:

http://schilytools.sourceforge.net/man/man1/make.1s.html

and try to understand what SunPro Make implemented for := in January 1986 - 
long before gmake existed. Maybe you understand your current misconception in 
depth. You already admitted your misconception and this is a good starter :-)

Hint: the explanation is currently on page 17 and page 31.

> >> The article "Recursive Make Considered Harmful" by Peter Miller
> >> (http://miller.emu.id.au/pmiller/books/rmch/ [^] and
> > 
> > This is an article from a person that does not know make(1) in depth (in 
> > special not the features from SunPro Make). The problems mentioned there are
> > all solved by autoatic dependency handling via .KEEP_STATE: from SunPro 
> > Make 
> > (introduced in January 1986) and the automatic library dependency handling 
> > from SunPro Make via .KEEP_STATE: since approx. 1992.
> 
> Peter Miller (who has deceased) was quite expert in make, specifically GNU 
> make:
> https://accu.org/journals/overload/14/71/miller_2004/ 
> 
> I realize you (Joerg) are partial to SunPro make, but many people are *never* 
> going to use
> SunPro make and simply don?t care about it.
> GNU Make is required for building many software systems,
> including GCC (since version 3.4), the Linux kernel, LibreOffice, and Mozilla 
> Firefox.
> For many people, ?make? *is* ?GNU make?.

That does not change the fact that the claims in 
https://accu.org/journals/overload/14/71/miller_2004/ have been outdated long 
before that text was written, since the problems have been identified and 
fixed before - see .KEEP_STATE:
 
> The *reason* that ?GNU make? is ?make? to many people is
> partly because GNU make is a good implementation, and that?s fine.
> However, it?s also because *practical* use of make often requires features 
> that are
> not standardized in POSIX. The POSIX standard for make is dreadfully 
> impoverished today.
> Adding at least one *standard* way to implement immediate execution is a step 
> towards
> having a more powerful *standard* for make. That not only helps portability,
> but it also encourages use of these more powerful mechanisms (*because* they 
> are standardized).

The reason for that problem is the fact that gmake is incompatible to other 
make implementations and that caused problems in finding ways to get to a 
common way. I am trying to get POSIX make to be extenxed since a really long 
time in order to finally include the minimum set of common features needed for 
a portable makefile method.

We currently still miss implicit pattern rules in POSIX and I really hope that 
we find a way to standardize at least the minimum subset for ISSUE 8 that 
would permit portable makefiles.

BTW: gmake is the only make implementation that implements the minimum feature 
set needed for modern portable makefiles that at the same time is a constant 
source of problems caused by bugs. If you are in a bubble that only knows 
gmake, you may arrange yourself with these bugs, but if you intend to permit 
your users to use any make implementation, gmake is not part of the solution 
because gmake still does not care about compatibility.

What I like to see in POSIX is a make definition that combines usability and 
interchangeability.

The reason for the success of UNIX was that people did look at other 
implementations and reimplemented good ideas from other implementations by at 
the same time avoiding clashes and incompatiblities. If that was true for 
gmake as well, this was a big win for the future.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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.
> > 
> > The :::= operator was introduced to smake and SunPro Make in March.
> 
> I can't consider this a real precedent.  Discovering ::= didn't work as
> expected then inventing a new operator and filing a request to
> standardize it almost the same day, and leveraging one person's
> maintenance of two different make sources to create "independent make
> programs", is just gaming the system.

Well, as mentioned before, :::= is just the operator that was intended by me 
when we discussed ::= for POSIX before I realized that gmake behaves 
incompatible and in a way that is not what people expect.
 
> If there's real precedent for it then surely someone can show me some
> makefiles somewhere that use :::= (or even BSD make := since, comments
> about prior implementation notwithstanding, I would guess there isn't a
> single real makefile out there today that uses :::=) in a way that
> can't be implemented with ::= instead.

There is plenty of := usage in BSD makefiles and :::= just standardzizes what 
BSD make and smake implemented via := before.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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:
> https://www.austingroupbugs.net/view.php?id=330
> 
> The ?::=? operator was selected because ?:=? had *incompatible* semantics 
> between BSD make and GNU make.

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.
 
> The article "Recursive Make Considered Harmful" by Peter Miller
> (http://miller.emu.id.au/pmiller/books/rmch/ [^] and

This is an article from a person that does not know make(1) in depth (in 
special not the features from SunPro Make). The problems mentioned there are
all solved by autoatic dependency handling via .KEEP_STATE: from SunPro Make 
(introduced in January 1986) and the automatic library dependency handling 
from SunPro Make via .KEEP_STATE: since approx. 1992.

> http://aegis.sourceforge.net/auug97.pdf) [^] notes this as a key problem when 
> creating makefiles,
> and strongly recommends using := instead."

Page not available - server down.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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
> missing `done'.

I would call this a bug in these shells.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 makefile today contains the :::= operator so every
> makefile that wants to use it will have to be changed, and in a way
> which is not backward-compatible with older versions of make).

You are mistaken.

The :::= operator has been implemented in two independent make programs before
it was standardized.

The :::= operator was introduced to smake and SunPro Make in March. At that 
time it did use the same behavior as smake and BSD make implemented the := 
operator since 30 years.

While diskussing that operator in the teleconference, we discovered that BSD 
make added .MAKE.SAVE_DOLLARS three years ago to deal with corner cases. We 
asked the BSD developers for their preference on whether $$ expansion should 
be disabled by default in case that a new operator was introduced that does 
not need to implement compatibility with the 30 year old := from BSD make and 
smake.

As a result of that, we decided that not expanding $$ is the right way to go 
and that behavior was implemented for :::= in smake and SunPro Make. The 
behavior was tested with the makefiles we developed before and a week after 
smake and SunPro Make introduced the complete behavior for :::=, the new POSIX 
feature was decided on and the current text was written.

So this is not invention but developing a new operator based on experiences 
with existing make implementations and soon after deciding on the standard.

If you like to test :::=, just compile a recent schilytools version and check 
smake and SunPro Make.

The support for the accepted behavior was first published in the 2021-08-14
version. The finally accepted POSIX text is from 2021-08-16.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

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 they sold the Copyright to SCO.
> 
> SVR4.2 ES/MP became Unixware 2.01.

Sure? I had such a machine for a while because I enhanced the cdrom filesystem 
driver to support Joliet and ISO-9660:1999, but I did not realize that the 
shell was changed.

Well, this of course is a change that needs testing to discover.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 implies that it executes
> the assignment statements in reverse order, in addition to carrying $?
> through the sequence of assignments.

You are right, the original Bourne Shell for unknown reasons did evaluate a 
series of shell variable assignments in reverse order. That was changed in 
ksh88 and in bosh.
 
> The SVR4.2 shell prints 1 42 1. I imagine the rest of the SVR4 line sh is
> the same.

Something called SVR4.2 does not really exist. It was a minor change compared 
to SvR4 announced by Novell short before they sold the Copyright to SCO.

I know of no customers for SVR4.2... even SCO seems to only used it internally 
in their project Monterey that was abandoned by IBM.

There have been major changes in the Bourne Shell for SvR4, but the $? was not 
touched. So you are mistaken.

The important thing to know here is that the Bourne Shell has some 
checkpoints that update the intermediate value of $?. Since that changed in 
ksh88 and since POSIX requires a different behavior compared to the Bourne 
Shell, I modified one checkpoint in bosh to let it match POSIX.

(exit 42); a=$? b=`false` b=$?; echo $? $a $b

prints

1 42 42

in bosh and

1 1

in the SvR4 Bourne Shell.



Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 = .WAIT
>   BAR: a $(FOO) b
> 
> then -- i have not yet really looked into that -- it seems GNU
> make uses "double expansion" and the above approach would possibly
> no longer work because.
> Is there wording in the standard that this is allowed?  Is this
> desirable?  Shall there be words that forbid such usage of .WAIT,
> or any other special target?  For example, in GNU make, i see

We discussed this in the teleconference and since I am using that feature in 
the schily makefile system, I expect this to work and I believe that our 
current wording requires it.

The background is that make, while parsing

BAR: a $(FOO) b

immediately expands $(FOO) in the reader, before the rest of the parser can 
see it.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

Re: utilities and write errors

[Joerg Schilling via austin-group-l at The Open Group]

"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 changed that to print the directory in case that the 
target directory name differs from the cd parameter.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

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 existing practice
> 
> Apparently not in most versions of sort.

If you call NetBSd "most versions"

it seems that all other sort implementations use a uniform definition
for -S and Netbsd is in conflict with "all other sort implementations", at 
least with Solaris, GNU, FreeBSD, OpenBSD.
 
>   | If you like to disable -s, better use +s
> 
> No, + options don't work in general, and would be even more difficult to
> support in sort because of keeping backward compat with its old key 
> specification syntax.

Given that the historic + usage with sort expects a digit past +, I see no 
conflict. 

> If we need a different option (really need) then we simply use a different
> option (for which we'd simply allow both, the new, and -S).

As mentioned, your proposal for -S is not compatible with most versions of 
sort.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 "last resort", or -w/-W for
> "whole line".

We already have +option in the standard, see the shell

The nice ting with +s is that it helps to be economical with option letters in 
a time, when there is a high risk to break existing implementations by 
introducing "new" option letters in POSIX.

BTW: The ast implementation and libgetopt from schilytools support +option
in getopt() already...

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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>
> 
>   | How do you believe is -S related to what -s could probably do?
> 
> The -S under discussion is simply !-s (as -s is !-S) - switches between
> stable sort (-s), using only designated keys to make order decisions,
> and original sort (-S) fallback to full record comparisons.

That would be in conflict with long existing practice

If you like to disable -s, better use +s



Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 unspecified.

How do you believe is -S related to what -s could probably do?

-S is in use to set up the virtual mamory for sorting since at least 23 years.

Do you have a different meaning in mind?

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 between both versions is te 
missing warning in /usr/xpg4/bin/sort.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

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\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 variant to avoid the message.
> [...]
> 
> I suppose you mean the -C option, which
> still checks but doesn't output a diagnostics message.

No, I was referring to /usr/xpg4/bin/sort

~A

/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 variant to avoid the message.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

Re: utilities and write errors

[Joerg Schilling via austin-group-l at The Open Group]

"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 it). I guess their
> ?~>&? confused me. My point of _please_ using ?>file 2>&1? instead
> is still valid, ofc.

BTW: I would not call it a hard parse error but a semantic problem, since the 
standard only mentions numbers after >&

ksh

echo bla >& /dev/zero
ksh: /dev/zero: bad file unit number

Bourne Shell

echo bla >& /dev/zero
/dev/zero: bad number

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

Re: utilities and write errors

[Joerg Schilling via austin-group-l at The Open Group]

"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 tried to write() to
>   | standard output.
> 
> But did it "encounter" the error?   Generally to encounter something
> you need to be looking for it (except in the case where the issue jumps
> up and bites you).   If you don't look, you don't encounter it, you simply
> pass by.

It could be argued that setting up PWD is the main task for pwd and that did 
succeed.


Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

Today is the 80th anniversary of the computer

[Joerg Schilling via austin-group-l at The Open Group]

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.

https://en.wikipedia.org/wiki/Z3_(computer)

https://en.wikipedia.org/wiki/Konrad_Zuse

People who like to see this computer working may see a replique made with
modern relais. This replique was build by his son Horst Zuse in Berlin and is 
presented in the Technikmuseum Berlin. This museum also presents a replique of 
it's mechanical precursor, the Z1 (finished in 1938).

https://en.wikipedia.org/wiki/Z1_(computer)

https://en.wikipedia.org/wiki/Horst_Zuse

http://www.horst-zuse.homepage.t-online.de/z3-detail.html

http://www.z3-computer.de/ This is how the replique is presented in Berlin.

If you visit Berlin. you may call Horst Zuse to get a private demonstration
in the Technikmuseum. Check his E-mail from his website.

Given that last year was the 51th anniversary of UNIX, more than half of the
time computers exist, they run with UNIX.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

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 
> . I will try to figure 
> out why I am getting different results from you.

OK, it depends on usage, so you may have tested the "wrong" way:

ksh93 -c 'PATH=/tmp/:$PATH; gcc'
gcc: no input files

ksh93 -ic 'PATH=/tmp/:$PATH; gcc'   
ksh93: gcc: not found [Datei oder Verzeichnis nicht gefunden]

ksh93 -c 'PATH=/tmp/:$PATH; gcc; hash'
ksh93[1]: gcc: not found [Datei oder Verzeichnis nicht gefunden]
gcc=/tmp/gcc

ksh93 -c 'PATH=/tmp/:$PATH; gcc; echo'   
ksh93[1]: gcc: not found [Datei oder Verzeichnis nicht gefunden]

this looks strange...

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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.
> 
>   | in that files of this type are not load images exec() is to handle
> 
> There is no specification at all of what file types exec() is to handle.
> 
> Anything that the system can run, no matter how it does that, is acceptable.

Correct, on Solaris the e.g. includes precompiled ksh93 scripts.

You can compile a ksh93 script with the command "shcomp" and the result starts 
with:

^k^s^h\0

The Solaris kernel detects this and starts ksh93 the right way with that binary.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

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 does not even 
> require the shell to fork at all, the shell may use some other 
> system-specific way of creating a new process. This isn't hypothetical, 
> such other system-specific ways of creating new processes were the 
> reason posix_spawn was added, and posix_spawn appears to be used by at 
> least one shell (ksh).

This was possible on ksh93 because ksh93 installed the needed infrastucture for 
Win-DOS in order to support UWIN.

Do not expect other shells to be able to follow that easily.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

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 redirects etc have
> all been done).  This one is the subsequent search, which starts out
> with what is already in the hash table (assuming the command was found
> at all) and then if that fails, goes ahead and looks for another.

This is the method from the Bourne Shell and I also expect this to be used.
The Bourne shell btw uses the hash as the start value for the search in thew 
forked child.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 continues. This precludes "#!" being recognized as any of those. 
> There is NO allowance for '!' being the second character as reserved for 
> implementation extensions.

#!/bad of course is a normal comment from the vew if a normal shell. 
An execption is mz old "bsh" (not bosh) on a historic UNIX without support for
#! in the kernel.

On all recent platforms, #! is just another *magic number* that is handled by 
the kernel only.

POSIX of course does not limit what magics are recognised by the kernel.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

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 it will fail, there are a lot of
> >> shells where command -v gcc returns /bin/gcc, but running gcc actually
> >> executes /usr/bin/gcc instead without reporting any error: this
> >> behaviour is common to bosh, dash and variants (including mine), ksh,
> >> and zsh.
> > 
> > My tests show that ksh, bash, yash, mksh do not find gcc in that case.
> 
> Huh. My tests with ksh were with 93v, it's possible different versions 
> behave differently.

Do you have a private variant og ksh93v?

I get the same behavior from  ksh88, the ksh93 from OpenSolaris and ksh93v.
 
> I am assuming that by "do not find gcc" you mean "do not find 
> /usr/bin/gcc" here.

As mentioned in another post, the error is ENOENT, caused by execiting the 
#!/bad script. So unlike the Bourne Shell, ksh does not use the hash as start 
index for further searching but rather as a definite value.

> > I believe what bosh and dash do is the best behavior. None of the known 
> > shells
> > opens the file with "command -v something" and thus cannot know whether the
> > content is a script, a useless #! script or even a binary for the wrong
> > architecture.
> 
> Earlier, you did not see the problem that prompted this thread, and now 

Well, with 40 years of UNIX history experience, you have so many exceptions to 
remember that you do not always remember every detail and the OP could at least 
give a hint.

> you say that the behaviour where command -v lookup does not match 
> execution lookup is the best behaviour. I trust that you do see now the 
> problem that prompted this thread: there is, in these shells at least, 
> no reliable way to perform command lookup separate from execution.

This is indeed a problem that that would need a coordinated change in all 
shells.

Fortunately, the problem is only present on missconfigured environments. It can 
be avoided by admins...

> I don't think command -v should do more, I think ordinary command lookup 
> should do less. The behaviour of shells of continuing command lookup 
> after a failed execve() is not supported by what POSIX says in "Command 
> Search and Execution". Command lookup is supposed to stop as soon as "an 
> executable file with the specified name and appropriate execution 
> permissions is found" (per the referenced "Other Environment Variables", 
> "PATH"). In my example that results in /bin/gcc. The shell should 
> attempt to execute /bin/gcc, and once that fails, stop.

Given that #!/bad causes an ENOENT, this seems to be a missinterpreation from 
you. The shell cannot distinct the missconfigured script from a missing file.

> > There is still a problem: only bosh and ksh could in therory add the right
> > entry into the hash, since they are using vfork() and could report back the
> > final result via shared memory. I have that probability in mind for bosh 
> > since
> > I introduced vfork() support to bosh in 2014.
> 
> That's an interesting thought. The approach taken by the other shells 
> avoids the problem entirely and makes this unnecessary though.

Not by all shells, see e.g. dash.

The Bourne Shell and dash behavior seems to be the expected behavior since I 
would not first look at how the hash entries are created in order to judge on 
the real execute behavior.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 
> body of the script after the shebang line, without any token expansion, to an 
> alternate interpreter via an exec() of some sort. Second, conforming 
> applications can not rely on unspecified behaviors, so having a use beyond 
> that specified makes the shell nonconforming. Calling it out like that simply 
> acknowledges a lot of shell implementations choose to make themselves 
> nonconforming, I do not see it as an endorsement or allowance. The 
> requirement explicitly specified behavior shall be implemented as specified 
> takes priority. Some conforming script authors may simply want the first line 
> to be a# IMPORTANT USAGE NOTE headline, or similar, not want a 
> utility named "!!!" to be exec'd.

You are mistaken again.

The only platform that worked like you describe is my old shell "bsh" when
run on UNOS (the first UNIX clone).  But this was in the 1980s and there is no 
other similar platform.

Today, #!/path is always handled by the kernel.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 continues. This precludes "#!" being recognized as any of those. 
> There is NO allowance for '!' being the second character as reserved for 
> implementation extensions.

No, sorry but #!/path is a kernel extension that is permittd by POSIX.

The shells handle such a line as comment

Also note that the error code from exec*() for a file that contains #!/bad is 
not ENOEXEC, but ENOENT. This is why the shells continue to search for a 
potential executable in PATH when they actually try to execute thw binaries.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 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 shells.
> > It therefore cannot give useful results in a standard
> > shell environment.
> > 
> > Even worse: On Linux, "which" may be a program with different
> > behavior.
> 
> The OS kernel is hardly relevant here. Various Linux-based OSes

Did I write Linux kernel?

If you tell other people they are not 100% precise, please carefully read 
what you are replying to.

> use various implementations of "which". On Debian-based systems,
> these days, it's implemented as a POSIX sh script (regardless of
> whether Linux (most common by far), kFreeBSD, Hurd, Illumos...
> is used as the kernel)

Do you like to say Illumos did replace the original csh script by something 
that is incompatible? I cannot confirm that.

> > 
> > typeis built into the shell since 1976. What problems do you
> > have with it?
> 
> No, actually type was added to the Bourne shell in SVR2 released
> in 1984, and had that problem that it would not return failure
> when failing to find a command (a bug which survived well into
> the 90s on some OSes IIRC).

OK, I did forgot to first check Sven Maschek and just wrote what I had in mind.
 
> The fact that "which" came first largely explains why it's still
> more popular (even if more broken and less useful in shells
> other than tcsh/zsh) than "type".

I did use "which" in the early 1980s, but at that time, the Bourne Shell was 
not a nice interactive shell, so I used my old "bsh". In 1986, SunOS switched 
to the SYSV Bourne Shell and that had "type". That is really a long time ago.

Most people who currently belive "which" is a good idea, did use diapers
in 1986. So that does not seem to be the problem.

I guess the reason for the problem we see today is caused by bad advise from 
the internet.

> > command is POSIX standard. What problems do you have with it?
> 
> Technically, a "command" builtin was added to zsh first in 1990.
> POSIX.2 introduced a "command" builtin with different
> semantics for sh in 1992.

Interesting: command indeed was added to the POSIX variant of ksh88 in 1995.
I thought it was a ksh88 invention.

> Most of that and much more was already mentioned at
> https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then
> as referenced in the OP's original message.

That was too long to read.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 so that any attempt to execute it will fail, there are a lot of 
> shells where command -v gcc returns /bin/gcc, but running gcc actually 
> executes /usr/bin/gcc instead without reporting any error: this 
> behaviour is common to bosh, dash and variants (including mine), ksh, 
> and zsh.

My tests show that ksh, bash, yash, mksh do not find gcc in that case. bosh and 
dash execute the correct gcc binary, but still have the wrong script path in 
their hash after calling gcc.

I believe what bosh and dash do is the best behavior. None of the known shells 
opens the file with "command -v something" and thus cannot know whether the 
content is a script, a useless #! script or even a binary for the wrong 
architecture. 

This is a result of the layering that has been introduced in the past 50 years 
of UNIX.

If command -v should become able to do more, we would need to invent a way to 
execute _any_ utility (regardless of whether it is a binary or script) to 
execute in a harmless way without side-effects.

There is still a problem: only bosh and ksh could in therory add the right 
entry into the hash, since they are using vfork() and could report back the 
final result via shared memory. I have that probability in mind for bosh since 
I introduced vfork() support to bosh in 2014.

If that was implemented and command -v was used with a well known command like
gcc, there could be a way to get the finally correct result from command -v:

1)  call "gcc --version 2>&1 > /dev/null"

2)  if that resulted in $? == 0, call: "command -v gcc"
The output now could reports what is actually used, in case that
the finally used binary path was reported back via shared memory.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 shells.
It therefore cannot give useful results in a standard
shell environment.

Even worse: On Linux, "which" may be a program with different
behavior.

typeis built into the shell since 1976. What problems do you
have with it?

command is POSIX standard. What problems do you have with it?

whence  is a ksh specific command and thus non-portable

where   ??? what is that?

whereis does not exist on a typical UNIX system

whatis  is a command that behaves like "man -k"

hashis POSIX standard, it allows to query all hash entries or
to add a potential hash entry.

> As for `command -v`:
> It is not possible to know the path of the executable without executing 
> it. This is however slow, since the shell environment has the paths in 
> memory or it is even cached. It can also have potential unexpected or 
> dangerous side effects, since command behavior (without arguments) and 
> command arguments can be deviating.

This is not correct.

"command -v" does not execute the command. It rather imitates the PATH lookup
procedure without executing the command.

> 1. Are there plans to allow introspection to the shell environment as to 
> prevent failures and enforce basic semantics of words?
> I am thinking of ways to differentiate 1.aliases, 2.functions, 
> 3.builtins and 4.executables in and not in $PATH both machine and 
> human-readable where sufficiently simple (otherwise human readable).
> This list may be incomplete.

This does not seem to be related to the statements you made above.

If you like help, you could make it easier if you could explain more in depth
what you like to do and what exact problems you have.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 result of the 
> first opening parenthesis. However, before the first opening 
> parenthesis, an opening parenthesis is accepted, while after the first 
> opening parenthesis, an opening parenthesis is not accepted. Since the 
> two states differ in what they accept, they cannot be the same state. 
> Therefore, the opening parenthesis did cause a state change.

Given that only "(" is thrown away without modifying internal variables, there 
is no state change.

> > The problem here is that the lexer sees the '(' as a separate token and 
> > thus it 
> > is seen as pattern. The next token is the "x" and since "x" is neither ')', 
> > nor '|', this syntax is not accepted.
> 
> The error message in both bosh and ksh is "`(' unexpected". This error 
> message means the shell rejected the '(' token, not whatever follows. Of 
> course it did: a pattern cannot be any arbitrary token, it has to be 
> what the standard calls a "word", which '(' is not.

Well, I should have been a bit more specific.

The code is:

  if (wdval || (word() != ')' && wdval != '|')) 
synbad(); 

and wdval is the return value from the previous word() call. Wdval is == 0
in case that the parsed word is recognized as a string. As I mentioned, '(' is 
not recognized as a string as I mentioned before.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 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 does not happen in ksh and the Bourne Shell as mentioned
> > before.
> 
> That state change clearly does happen and the exact example that I 
> included and you quoted shows that it does.
> 
> $ 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.

The problem here is that the lexer sees the '(' as a separate token and thus it 
is seen as pattern. The next token is the "x" and since "x" is neither ')', 
nor '|', this syntax is not accepted.

The problem here is that "(" is not a reserved word that would expicitly not 
handled special at this location in the case statement but rather parsed by a
hard coded algorithm in the lexer. That code in the lexer detects the special 
symbol '(', even though the parser flag "IN_CASE" is set, that otherwise 
disables a reserved symbol lookup.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 == '(')
>   token = next_token();
> 
>   if (token == ESAC)  /* not quite as simple as that, 
> but ... */
>   break;  /* from the enclosing loop which
>  loops over the patterns, and code */
> 
>   if (token != WORD)
>   error(...);

As mentioned in my previous mail, this test order does not match the test order 
used in ksh or the Bourne Shell.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 does not happen in ksh and the Bourne Shell as mentioned 
before.

BTW: Both ksh and Bourne Shell accept:

case esac {
   esac) echo match
}

In case of the alternate "in" symbol, an unescaped } would not be accepted as 
pattern.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 permitted merely to
> match the ')' required after the pattern (both for user style reasons,

This is a missunderstanding.

It is not a special state that causes a syntax error or not in this case.
It is rather the order of tests in the parser that causes the observed behavior.

The case parser function is called recursively to handle the unknown number of
case switches. It first checks whether the current token is "esac" and returns.
This is to permit the last case to end without ;; before the esac.

But since the test for '(' and the skipping of that supefluous thing is past 
the check for "esac", this chec will not hit with (esac).

This applies to the immplementation of ksh and the Bourne Shell.

It would be interesting to know whether shells that accept

case easac in

esac) echo yes
;;
esac

also accept the same without ;;

BTW: are there shells that support the statement without '('?

> and to handle this common usage of a lone ')' for shells that used
> parentheses counting to find the end of a $() cmdsub ... the latter doesn't
> work anyway, and is largely gone everywhere now, but the optional (and
> supposedly meaningless) '(' remains.

Well, the '(' is meaningless unless you use it to guard the pattern...

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 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 say.
>  |
>  |You are correct,
> 
> Yep -- unfortunately.

I meanwhile discovered (from a hint in another mail in this thread that I canot 
answer) that the trigger may be an embedded nul character.

The s-nail error message was:

"Failed to prepare composed message"

and the mail display (before I tried to answer) stopped before the line that
contained that nul character. Again saving the mail to a file and using iconv(1)
did result in "useful" converted output.

There seem to be two things that need to be handled in a way that never causes
a mail (regardless of the content) to prevent reading or answering.

-   EILSEQ should not result in shortened mails or errors that abort
work completely for that mail.

-   Characters that cause EILSEQ should be transformed into "something"
in the output that at least is a hint for that problem.

I am not sure whether that helps, but I remember from my experiences from 
mkisofs that iconv() from glibc has a bug and ignores *outbytesleft. This
frequently results in reading or writing too much data.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

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 say.

You are correct,

I have been able to save the mail as file and to run iconv(1) on the content.
Maybe a problem is that the first missing line is a line with a character that
is not part of ISO-8859-1

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 do that as well, so I got the same truncated mail back :( other
> than qmail, exim is known to break the MIME and SMTP standards like that).

Thank you for this information.

> >From IRC:
> 
> 15:57 < orbea> yash matches the bash behavior fwiw
> 16:26 < orbea> pdksh, oksh, loksh, zsh and posh match mksh's behavior with 
> 'exec', everything else including
>ksh2020 and hsh match bash/yash
> 16:26 < orbea> as reproduced with: ls () { echo foo; }; exec ls
> 16:27 < miskatonic> and the difference is what?
> 16:28 < orbea> mksh prints 'foo', yash executes ls(1)

OK, mksh pdksh and posh have te same origin.
I don't know oksh, loksh

> I can live with it being open to implementations as well, but it's
> best to clarify.

Well, the Bourne Shell man page says:

 The command specified by the arguments  is  executed  in
 place  of  this  shell  without  creating a new process. ...
 
The POSIX text is:

If exec is specified with command, it shall replace the shell 
with command without creating a new process. ...

So the main statement in both is that the command is executed in place of 
the shell. This seems to be obviously a hint that the shell cannot run 
anymore and thus the function cannot be executed.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 
> looks on path instead and finds the utility.
> On Wednesday, December 9, 2020 Thorsten Glaser via austin-group-l at The Open 
> Group  wrote:
> Hi *,

Hi,

here is where the original mail ended for me. Interesting that you did get
more content. Is there any idea, why I received only the first line from the
original mail?

...
 
> I???ve got a report in IRC by a user who spotted a cross-shell difference.
> 
> In my opinion, the invocation???
> 
>     sh -c 'ls() { echo meow; }; exec ls'
> 
> ??? is supposed to output "meow\n and return to the caller with a zero
> errorlevel.
> 
> Some shells execve() the ls(1) binary instead.

Thorsten,

do you know any shell besides mksh and zsh that call the function with this 
command? 

>From my understanding, calling the function is a bug.

Important for me is that the Bourne Shell, ksh88 and ksh93 call ls(1), so this 
is historically correct and it was not seen as a problem by David Korn.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

"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 makes a difference - but for now, it seems clear
> that duplicate rules should simply result in unspecified behaviour.

I am not proposing to add this feature with the next version of the standard.
I am however interested in avoiding to leave things open to changes, so some
make implementations could not introduce future changes that may prevent
enhanced definitions in the standard. The most important problem with 
standardization today is diverging/contradicting features.

This did not happen in the 1980s when OSS was not usual. In the 1980s, other 
platforms typically reimplemented new useful features from other platforms 
within 2-3 years. Today, people do not even check whether their idea might
be in conflict with a better implementation from another platform.

> I don't work on make (as you know) but I suspect that if we ever implemented
> a method of replacing existing rules, that warning would go away.

I know that you are not woking on bmake. But maybe you can help to convince the 
right people to fix bmake. The current most problematic bug in bmake is that it
expands:

$(FOO:%=bar/%)

with an empty $(FOO) into "bar/", but it should expand into nothing.
If that bug was fixed, then bmake could most likely be used for the schily
makefilesystem.
 
> As it is now, whether the replacement has code attached, or not, makes
> no difference, so your proposal would generate the warning if given to
> an unmodified bmake just the same as the gmake method.

The point here is that a direct replacement command could cause the wrong
assumption that the command is modified in place instead of appending a new
rule. You have been a victim of this missinterpretation already.

This is why I prefer to have the need for first explicitly removing the rule 
first, since this makes the behavior obvious.

Jörg

-- 
EMail:jo...@schily.net  Jörg Schilling D-13353 Berlin
Blog: http://schily.blogspot.com/
URL:  http://cdrecord.org/private/ 
http://sourceforge.net/projects/schilytools/files/

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

[Joerg Schilling via austin-group-l at The Open Group]

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 (report mode) and to permit only a single limit type related 
flag in case the limit is going to be set.

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
  Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

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

[Joerg Schilling via austin-group-l at The Open Group]

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 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 pattern rule can be overwritten at any time,
> > > including the default pattern rules.
> > 
> > This is how pattern rules have been defined when they appeared in
> > SunPro Make in January 1986.
>
> Well, it's not how pattern rules in GNU make work.
>
> > The fact that gmake overwrites existing pattern rules is not
> > sufficient (as it does not permit to remove them)
>
> That is not the case.  You can absolutely remove them.

The accepted way on UNIX for copying ideas from other implementations is to 
create a compatible clone with no "incompatible enhancements".

My idea is to start with a subset of the features of the original 
implementation and to add some commonly *agreed* new features.

This could be new features to remove single pattern rules or all pattern rules.

> I don't understand the distinction you're trying to draw between
> "disabled" and "deleted".  Regardless, if you define a pattern rule
> with no commands then the previous pattern is gone and cannot be "re-
> enabled", so I think "deleted" is the correct term.

Well, the fact that gmake still lists a "deleted" rule with gmake -p is 
confusing users. I just verified that gmake in fact correctly adds a new 
pattern rule with the same patterns of a deleted one to the end of the list.

> Yes, that could be done.
>
> It's different than MAKEFLAGS += -r, however, because the latter is
> guaranteed to only delete the _built-in_ rules.  This is almost always
> what the user wants.

As mentioned before: internal rules need to be parsed before reading the users
Makefile, so a line in the form

MAKEFLAGS += -r

in the users Makefile is inefficient unless you ignore the rules for the 
precedence of definitions that are in POSIX.

> Having "%:%" delete ALL the existing pattern rules is problematic
> because it relies on a specific ordering of appearance in makefiles.
> I'm sure such a feature would lead to a lot of head-scratching followed
> by cursing once a stray "%:%" pattern was discovered down in the bowels
> of the makefile system.

Given that pattern rules _are_ based on the concept of a specific ordering, 
this is a perfect enhancement.

People who may get problems with that, are obviously using unplanned Makefiles.

> I would prefer to use a special target which forced all built-in /
> system rules (only) to be dropped, something like:
>
>   .NOBUILTINS:

This may be a useful potential enhancement, but this would still differ from

$make -r

since .NOBUILTINS: would only affect rules from the internal makefile, but not
disable macro defitions.

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
  Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

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

[Joerg Schilling via austin-group-l at The Open Group]

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, it started with 
the wrong intention.

The important point is that you need pattern rules if you like to put 
compilation results into platform specific sub-directories.

I like to get pattern rules into the standard by only requiring a subset of 
what 
has been available since January 1986.

The documentation is currently on page 30 of the man page:

http://schilytools.sourceforge.net/man/man1/make.1s.html

I would only standardize the form:

   tp%ts: dp%ds
rule

and mention

   tp%ts: [dependency ...] dp%ds [dependency ...]
rule

only as a potential enhancement that is not part of the standard.

Smake e.g. currently only supports:

   tp%ts: dp%ds 
rule

and 

   tp%ts:
rule

BTW: this reminds me that I need to add documentation for:

   tp%ts:
rule

Note that the behavior of SunPro Make was not changed since 1986 with regards 
to pattern matching rules.

Do you believe we have a chance to get to a text for Issue-8?

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
  Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

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

[Joerg Schilling via austin-group-l at The Open Group]

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 need to use "make -r".
>
> Sure, it's easy to redefine a suffix rule.  The issue in question was
> that Geoff wanted to not use the .c.o rule at all.  He wanted to use
> other rules to build .o files in other ways, but the .c.o rule was
> interfering with it.  There's no way to DELETE that .c.o rule other
> than -r.

Well, this indeed is a problem with the suffix rules. You need to be careful to 
understand their working method correctly. But I expect people to either not 
touch these rules at all or to learn how to use them first.

smake in former times had simple suffix rules this way:

.o: .c .s .l
$(CC) -c $(CFLAGS) $(CPPFLAGS) $<
$(AS) -o $*.o $(ASFLAGS) $<
$(LEX) $(LFLAGS) $<;$(CC) -c $(CFLAGS) lex.yy.c;rm lex.yy.c;mv lex.yy.o 
$@

which is easier to understand, but I stopped to define them 21 years ago 
because three methods for implicit rules (simple suffix, suffix and pattern) 
most
likely are too much for users.

> In fact, GNU make allows users to disable built-in rules completely
> WITHOUT having to require users to add -r to the make command line,
> because it allows users to add this to their makefile:
>
> MAKEFLAGS += -r

I would not call this an advantage, since it is in conflict with all other
make implementations and people that may have seen this to work (how ever) in 
gmake, will realize that this cannot work if you follow the lines of POSIX and 
first read the internal rules and then the external makefiles. If a make 
implementation reads the external makefile, it is thus too late to disable the 
internal rules unless you introduce dirty tricks that are not compatible to the 
POSIX definitions.

> and it does the right thing.  Of course this is problematic as well
> because that is now passed to sub-make invocations which may not be
> what you want.  However, in practice it is rarely a problem.

This is true, if you pass this to sub-makes, it is not too late...

> In fact, most of the built-in rules in GNU make ARE defined as suffix
> rules; see this from default.c:
>
> ".c.o",
> "$(COMPILE.c) $(OUTPUT_OPTION) $<",

I cannot confirm this, gmake at the same time defines

%.o: %.c
#  recipe to execute (built-in):
$(COMPILE.c) $(OUTPUT_OPTION) $<

whis is a rule with precedence before suffix rules.

> However, GNU make also provides a number of built-in rules that cannot
> be expressed as suffix rules, such as these:
>
> /* RCS.  */
> { "%", "%,v",
> "$(CHECKOUT,v)" },
> { "%", "RCS/%,v",
> "$(CHECKOUT,v)" },
> { "%", "RCS/%",
> "$(CHECKOUT,v)" },

Classical make implementation (and in this special case, this also applies to 
SunPro Make) implement this hardcoded in C. This is why I so far have been 
hesitant to define similar rules in smake. RCS is non-standard, dead and slower 
than SCCS anyway, so this does not seem to be a problem ;-)

> > - pattern matching rules have precedence over suffix rules and may 
> >   themselves not be overwritten
> > 
> > - pattern matching rules match in the order of their apperance to the
> >   parser. The first pattern rule that matches a specific pattern is 
> >   used. Later specifying a replacement rule for a specific pattern is
> >   impossible.
> > 
> > - The built in default rules must to be "read" by make before the 
> >   users makefiles are parsed in order to allow them (the suffix
> >   rules) to be overwritten. Any pattern matching rule that appears
> >   in the builtin default rules thus would have precedence over 
> >   anything else and cannot be overwritten.
>
> Maybe these are problems in SunOS make / smake, but they are certainly
> not problems in GNU make.
>
> I'm not sure where the idea that pattern rules are immutable comes
> from: in GNU make any pattern rule can be overwritten at any time,
> including the default pattern rules.

This is how pattern rules have been defined when they appeared in SunPro Make 
in January 1986. 

If this was a problem, people could have made a bug report at that time but 
this did not happen Given that pattern rules are not (neither in SunPro 
Make, nor in smake) used in the built in rules, there is no need to have a 
method to remove them later, since they are only used by the user makefiles.

Since I tend to avoid a hard coded implementation for SCCS support in smake, I 
tend to introduce SCCS checkout support in a future version of smake using 
pattern rules. This would introduce the need to be able to withdraw existing
pattern rules selectively.

The fact that gmake overwrites existing pattern rules is not sufficient (as it 
does not permit to remove them) and it is a non-compliance related to the 
original definition so t

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

[Joerg Schilling via austin-group-l at The Open Group]

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.
>
> Hm.  Right, I forgot that clearing the suffixes doesn't also delete the
> rules.  It's annoying that there's no POSIX way to delete the default
> rules from within the makefile.

There is no need to do that.

In former times, there was no way to clear .SUFFIXES, but at that time, SunOS 
defined default rules that look this way:

SUFFIXES= .o .c ...
.SUFFIXES: $(SUFFIXES)

so you could clear it by overwriting the SUFFIXES variable from your user 
makefile.

Now POSIX requires that writing:

.SUFFIXES:

into a Makefile clears the suffix list and thus effectively disables all default
implicit rules.

If you only like the .c.o rule but are not happy with the builtin default rule 
for e.g. .c.o:, you can overwrite it by e.g. writing:

.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 need to use "make -r".

> In my opinion the -r option is wrong.  Whether or not the default rules
> should be used is a function of the _makefile_, not a function of the
> _user_ of the makefile (the person who runs make).  If the makefile is
> written so that it doesn't want or need the default rules then the
> makefile should be able to delete them.  It shouldn't be up to the
> invoker of make to do that.

Well GNU make makes the mistake to define pattern matching implicit rules in 
its default rules and this causes the following problems:

-   pattern matching rules have precedence over suffix rules and may 
themselves not be overwritten

-   pattern matching rules match in the order of their apperance to the
parser. The first pattern rule that matches a specific pattern is 
used. Later specifying a replacement rule for a specific pattern is
impossible.

-   The built in default rules must to be "read" by make before the users
makefiles are parsed in order to allow them (the suffix rules) to be
overwritten. Any pattern matching rule that appears in the builtin 
default rules thus would have precedence over anything else and cannot
be overwritten.

For this reason, SunPro Make intentionally does not make use of pattern 
matching rules in the builtin default rules in order to permit the user to 
have full control over the behavior of make without a need to call "make -r".

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
  Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

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

[Joerg Schilling via austin-group-l at The Open Group]

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
>   rules for the pathname that were parsed before the include line
>   was parsed shall be used to attempt to create the file or to
>   bring it up-to-date before opening the file.
>
> 2. The "delayed remaking" method
>
>   If make uses this method, no attempt shall be made to
>   create the file or bring it up-to-date until after the
>   makefile(s) have been read.  During processing of the include
>   line, make shall read the current contents of the file,
>   if it exists, or treat it as an empty file if it does not exist.
>   Once the makefile(s) have been read, make shall use any
>   applicable target rule or inference rule for the pathname,
>   regardless of whether it is parsed before or after the include
>   line, when creating the file or bringing it up-to-date. 
>   Additionally in this case, [...]
>
> If the pathname is relative, [...]

Sorry, but this would result in non-portable makefiles and it is not acceptable.

In order to permit portable makefiles, all rules to make/remake include files 
need to be before the include statement.

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
  Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

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

[Joerg Schilling via austin-group-l at The Open Group]

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 include files, if it is no longer the
> recommended way of doing things.

I am not sure whether I missed something, but I cannot see a method that may 
work in a portable way and unless I missed something, I see no new idea that 
makes things really better than what we are currently discussing.

The problem I see is that the advanced method available with SunPro Make does 
not seem to be supported by GNU make and the options mentioned in the paper 
from above seem to be GCC specific and still require a separate compiler call. 
The intention for POSIX however is to standardize portable solutions. This is 
why I believe that the current solution from bug 1325 is the right way to go 
in the close future.

The method based on cc -E as distributed by the schily makefilesystem has been 
verified to be portable to virtually any platform - even to the Microsoft 
compiler, see the shell script conf/mkdep-msc.sh

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
  Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

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

[Joerg Schilling via austin-group-l at The Open Group]

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 acceptable common subset.
> > 
> > No, sorry, that is a misunderstanding.  Like i have written, .WAIT is
> > for now all i would like to see a word about.
>
> I see.  Well, I'm not sure how feasible it is to add something like
> .WAIT to the POSIX standard, in the absence of any other discussion of
> parallel builds.

Well this is true. As long as POSIX does not mention parallel builds at all, 
it makes no sense for .WAIT to appear in a POSIX standard - except as a 
reserved special target.

BTW: I just implemented .NOTPARALLEL in SunPro make and the new feature will 
appear in the next schilytools release that will most likely be published next 
Tuesday.

Now it would be nice to have support for .NO_PARALLEL:  and for 
the .WAIT special target in GNU make. ... and the preinitialized make macro 
"MAKE_NAME" set to either "gmake" or "gnumake" (whatever you prefer) in order
to signal that this is a GNU make version that supports the new parallel make
features.

If GNU make did implement support for the .WAIT special target, I currently 
believe that it would be possible to work around the build ordering problems
that appear when GNU make runs in parallel mode and is going to rebuild more 
than one include file at the same time during startup.

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
  Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

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

[Joerg Schilling via austin-group-l at The Open Group]

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 all-compatible make rules with perl and
> POSIX tools, respectively): some words of the standard on the much
> desired parallelization of make.
...
> impossible to handle without massive build parallelization.  And
> whereas i understand that -j is not standardized, i think it would
> make sense to add some words about .WAIT, which seems to be
> reserved or reservable by all makes.  The situation is that
>
>   .NOTPARALLEL:
>
> For GNU make (not so much BSD make)
>
>   .WAIT:
>
> Luckily BSD make and the Sun makes and Schily make support
> specifying this as target, too, even though they use it as
> a built-in "special source" (or keyword), because otherwise the
> entire mechanism would require specific top-level make files for
> the different make programs!

Yes, the speudo target .WAIT has been introduced into SunPro Make
with Solaris 2 and it pemits to get fine grained control to parallel execution 
since it gives a way to require all targets to the left side of .WAIT to be 
made before targets on the right side are checked.

If GNU make did implement it as well, this would be a real benefit for 
controllability and portablity.

In my makefile system, I currently use a different assignment to work around 
the missing feature:

WAIT= .WAIT # on SunPro Make

WAIT=   # on GNU make

inside different files with rules that are read via "include". Then I use

target: a b c $(WAIT) d e f

that works to control parallel execution on SunPro Make and is ignored with
GNU make.

To make this easier to use, it would be extremely helpful, if other make 
implementations did provide a preassigned make macro

MAKE_NAME=  smake

MAKE_NAME=  gmake

or

MAKE_NAME=  sunpro

to use:

include $(MAKE_NAME)-rules

with make specific content.

Smake supports a predefined MAKE_NAME=smake since 1996 and the SunPro Make 
version I maintain supports MAKE_NAME=sunpro since May 2017, when I started
to maintain SunPro Make and added support for more than a single file type 
argument after the "include" directive.

Since .NOTPARALLEL seems to just overwrite the -j# command line option from GNU 
make by -j1, this does not seem to be hard to implement in SunPro Make.



Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
  Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

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

[Joerg Schilling via austin-group-l at The Open Group]

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 for sure, but it has been in the NetBSD
> source tree since 1993, which I think means it came from a CSRG BSD
> distribution (the log doesn't indicate explicitly) - after whjch it has had
> numerous fixes an updates by various NetBSD developers over the (many) years.
>
> The code does contain a (no longer used, that is, #if 0 surrounded)
> sccsid from CSRG:
>   static char sccsid[] = "@(#)printf.c8.2 (Berkeley) 3/22/95";
> but that appeared when 4.4-lite2 was merged in 1997, the original
> in the NetBSD source tree contained
>   static char sccsid[] = "@(#)printf.c   5.9 (Berkeley) 6/1/90";

OK, I checked the NetBSD repoand it does not see to be related to the FreeBSD 
version.


> The following has absolutely nothing to do with the issue I raised, but
> since you included it:
>
>   | The code from bosh has been written from scratch to fully support
>   | %n$ and this is what we should add to the standard in the near future.
>
> I'm not sure this is really required in the printf utility, as distinct
> from the printf (family of) functions, and causes all kinds of issues
> because of the way the utility reprocesses the format over and over until
> the args have all been used.

We are currently adding gettext(1) to POSIX and you need support for %n$
if you like to use gettext in a useful way in shell scripts.

> Eg: consider
>
>   printf '%1$d %4$d %2$d\n' 1 2 3 4 5 6 7 8 9 10 11 12
>
> What is supposed to be printed from that?
>
> Bosh appears to print
>
>   1 4 2
>   5 8 6
>   9 12 10

This is the identical output to what you get from ksh93 and from the FreeBSD 
printf. What you see is a side effect from the two constraints:

1)  Be compatible to the current POSIX standard

2)  Support %n$ in a useful way

> Now consider some other locale (the only reason for supporting this
> stuff at all is when locales need to print the args in different orders
> or different actual args, in order to correctly represent the language
> conventions) where the format string that is used is
>
>   '%1$d %3$d %2$d\n'
>
> With that one, bosh prints
>
>   1 3 2
>   4 6 5
>   7 9 8
>   10 12 11
>
> Now it has run the format string 4 times instead of just 3 previously,
> and has printed all the args, whereas previously it never printed 3 7 or 11.
>
> How is this useful?

This is the identical output to what you get from ksh93 and from the FreeBSD 
printf. 

There is a simple rule of thumb: If you like to use %n$ for localization, use 
a matching number of arguments and % units with printf(1).

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
  Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

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

[Joerg Schilling via austin-group-l at The Open Group]

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
> closer, I can see they are not actually the same - so those clearly have
> a builtin printf as well (they behave the same way as bash, the NetBSD sh
> and bosh).

If the code you are using is from FreeBSD (Garret Damore) then there are some 
minor bugs in it. Sorry, I no longer remember the exact problems

The code from bosh has been written from scratch to fully support %n$ and this 
is what we should add to the standard in the near future.

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
  Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

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

[Joerg Schilling via austin-group-l at The Open Group]

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&T corporate
> > (the commercial computer people there, back then) that made a dumb
> > decision is no surprise, they made so many...
>
> "It came from New Jersey" was always a common explanation for why
> certain things had happened in Solaris engineering.

Many of the new features from Svr4 have been developed by David Korn in 1988
and I definitely doubt that these interfaces are a result of dumb decisions.

> truss of "killall EXIT" and the Bourne shell builtin "kill -EXIT" does indeed
> show it making kill(pid, 0) calls to the processes - there's no check in the
> source for this, as you can see in the illumos sources:
> https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/killall/killall.c
> https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/sh/jobs.c

The same applies to the highly portable modern Bourne Shell that is POSIX 
compliant:

https://sourceforge.net/p/schillix-on/schillix-on/ci/default/tree/usr/src/cmd/bosh/jobs.c
https://sourceforge.net/p/schillix-on/schillix-on/ci/default/tree/usr/src/cmd/bosh/signames.c

> > I knew kill would use these functions, killall is the kind of interface
> > that I consider a clone (also pkill, etc).   All of those could make use
> > of a function like this - yet other systems somehow implemented those
> > commands without it, for decades...
>
> But presumably had more places to update signal name strings when defining
> new signals (not that it happens very often - we last did it a decade ago,
> when we expanded from 8 to 32 realtime signals to match Linux).

signames.c even has portable code that handles real time signals that at 
runtime (as in Linux) differ from the static definitions.

Since April 2020, this code has been updated to correctly deal with netbsd
see schilytools tarball.

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

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

[Joerg Schilling via austin-group-l at The Open Group]

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(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

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

[Joerg Schilling via austin-group-l at The Open Group]

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 things.

A nice idea from 1986 from SunOS-3.5 that did not make it into SVr4...

The question is whether this is POSIX compliant at all. If you like to see
such eintries, I would expect that you need to open() the directory with
a specific open flag first.

So my questtions:

-   When do you see such entries?

-   What happens when you stat() such a name?

Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'

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

[Joerg Schilling via austin-group-l at The Open Group]

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 makes it identical to 'a=', thus reducing the available
> functionality for no reason.
>
> I propose:



Looks good.

Re: Pseudoterminal terminology in POSIX

[Joerg Schilling via austin-group-l at The Open Group]

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:

   /dev/pty[p-r][0-9a-f] controller devices
   /dev/tty[p-r][0-9a-f] slave devices

so I would be OK with "controller" side and "terminal" side.


Jörg

-- 
 EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
 URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'