Re: [PATCH 3/4] Fit to Plan 9's ANSI/POSIX compatibility layer
- From
Kyohei Kadota <lufia@lufia.org>
- Date
- Aug 6, 2020, 13:49 UTC
- Message-ID
- <CAFMepcn-yWtke7eE006a5RGO6uaScWb2xZe4H5M8X4F_T4Rhbw@mail.gmail.com>
- In-Reply-To
- <20200806020407.GR6540@camp.crustytoothpaste.net>
Show 9 quoted lines
> 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.
Show 15 quoted lines
> > 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.
Show 7 quoted lines
> > 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
Show 7 quoted lines
> > 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.
Show 14 quoted lines
> > 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?
Show 28 quoted lines
> > +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