Re: [PATCH 3/4] Fit to Plan 9's ANSI/POSIX compatibility layer

[Kyohei Kadota <lufia@lufia.org>]

> On 2020-08-06 at 01:05:03, lufia via GitGitGadget wrote:
> > From: lufia <lufia@lufia.org>
> >
> > That haven't any commands: cut, expr and printf.
>
> Is this ANSI/POSIX environment the one mentioned at [0]?  That page
> describes it as supporting POSIX 1003.1-1990, which is a bit dated.  I
> think we generally assume one has the 2001 edition or later, so you'll
> have your work cut out for you.

Yes, the layer I told is APE.
I guess originally APE might be introduced for porting Ghostscript to Plan 9.

> > And its sed(1)'s label is limited to maximum seven characters.
> > Therefore I replaced some labels to drop a character.
> >
> > * close -> cl
> > * continue -> cont (cnt is used for count)
> > * line -> ln
> > * hered -> hdoc
> > * shell -> sh
> > * string -> str
> >
> > Signed-off-by: lufia <lufia@lufia.org>
>
> I will note that usually the project prefers to have a human's personal
> name here and in the commit metadata instead of a username.  Junio may
> chime in here with an opinion.

I see. I will rename them.

> >  command_list () {
> > -     eval "grep -ve '^#' $exclude_programs" <"$1"
> > +     eval "grep -v -e '^#' $exclude_programs" <"$1"
>
> Is it really the case that Plan 9's grep cannot deal with bundled short
> options?  That seems to be a significant departure from POSIX and Unix
> behavior.  Regardless, this should be explained in the commit message.

This is awful.
But now, APE's grep (/bin/ape/grep) is a simple wrapper for native
grep (/bin/grep),
its option parser is a very rough implementation.
https://github.com/0intro/plan9-contrib/blob/master/rc/bin/ape/grep

> >  get_categories () {
> > -     tr ' ' '\n'|
> > +     tr ' ' '\012'|
>
> Okay, I guess.  Is this something we need to handle elsewhere as well?
> The commit message should tell us why this is necessary, and what Plan 9
> does and doesn't support.

Yeah. I will edit the message.
Plan 9's tr(1) handles only \(16 bit octal) and \x(16 bit hexadecimal)
escape sequences.
If another character after leading backslash, tr(1) will replace \c to c.

> >       grep -v '^$' |
> >       sort |
> >       uniq
> > @@ -18,13 +18,13 @@ get_categories () {
> >
> >  category_list () {
> >       command_list "$1" |
> > -     cut -c 40- |
> > +     awk '{ print substr($0, 40) }' |
>
> I can tell that you haven't gotten the test suite working because I've
> added a large number of cut invocations there.  I suspect you're going
> to need to provide a portability wrapper there that implements it using
> awk, sed, or perl.

I see. If I'd like to put those wrappers to the repository, is there
the best place for them?

> > +if test -z "$(echo -n)"
> > +then
> > +     alias print='echo -n'
> > +else
> > +     alias print='printf %s'
> > +fi
>
> Let's avoid an alias here (especially with a common builtin name) and
> instead use a shell function.  Maybe like this (not tab-indented):
>
>   print_nonl () {
>     if command -v printf >/dev/null 2>&1
>     then
>       printf "%s" "$@"
>     else
>       echo -n "$@"
>     fi
>   }
>
> Notice also that we prefer the standard form and fall back to the
> nonstandard form if the system is less capable.  I don't know if Plan 9
> supports "command -v"; "type" may be preferable, but isn't supported by
> some other shells (e.g., posh).  For portability reasons, we may need to
> try to run printf and see if it fails.
>
> This is also going to need some patching in the testsuite, since we use
> printf extensively (more than 1300 times).  I do hope you have perl
> available.

In fact, Plan 9's ape/sh is pdksh, so it supports "command -v".
However I think, like the above comment, it might be better to create
the printf(1) wrapper.

---
kadota

> [0] http://doc.cat-v.org/plan_9/4th_edition/papers/ape
> --
> brian m. carlson: Houston, Texas, US