From: Kyohei Kadota <lufia@lufia.org> To: "brian m. carlson" <sandals@crustytoothpaste.net>, lufia via GitGitGadget <gitgitgadget@gmail.com>, git@vger.kernel.org, "KADOTA, Kyohei" <lufia@lufia.org> Subject: Re: [PATCH 3/4] Fit to Plan 9's ANSI/POSIX compatibility layer Date: Thu, 6 Aug 2020 22:49:43 +0900 Message-ID: <CAFMepcn-yWtke7eE006a5RGO6uaScWb2xZe4H5M8X4F_T4Rhbw@mail.gmail.com> (raw) In-Reply-To: <20200806020407.GR6540@camp.crustytoothpaste.net> > 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
next prev parent reply other threads:[~2020-08-06 17:23 UTC|newest] Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-08-06 1:05 [PATCH 0/4] Fit the building tools to Plan 9 environment KADOTA, Kyohei via GitGitGadget 2020-08-06 1:05 ` [PATCH 1/4] Use $(SHELL_PATH) instead of sh in Makefile lufia via GitGitGadget 2020-08-06 2:13 ` brian m. carlson 2020-08-06 4:10 ` Eric Sunshine 2020-08-06 14:39 ` Kyohei Kadota 2020-08-06 17:30 ` Junio C Hamano 2020-08-10 9:04 ` Kyohei Kadota 2020-08-06 1:05 ` [PATCH 2/4] Define TAR_CF and TAR_XF variables " lufia via GitGitGadget 2020-08-06 17:50 ` Junio C Hamano 2020-08-06 1:05 ` [PATCH 3/4] Fit to Plan 9's ANSI/POSIX compatibility layer lufia via GitGitGadget 2020-08-06 2:04 ` brian m. carlson 2020-08-06 13:49 ` Kyohei Kadota [this message] 2020-08-06 23:51 ` brian m. carlson 2020-08-06 23:57 ` Eric Sunshine 2020-08-06 18:10 ` Junio C Hamano 2020-08-10 10:53 ` Kyohei Kadota 2020-08-06 1:05 ` [PATCH 4/4] Use $(LD) instead of $(CC) for linking the object files lufia via GitGitGadget 2020-08-06 2:23 ` [PATCH 0/4] Fit the building tools to Plan 9 environment brian m. carlson 2020-09-09 19:47 ` [PATCH v2 0/2] " KADOTA, Kyohei via GitGitGadget 2020-09-09 19:47 ` [PATCH v2 1/2] Fit to Plan 9's ANSI/POSIX compatibility layer Kyohei Kadota via GitGitGadget 2020-09-09 19:56 ` Eric Sunshine 2020-09-09 20:34 ` Junio C Hamano 2020-09-10 0:35 ` Kyohei Kadota 2020-09-09 19:47 ` [PATCH v2 2/2] Use $(LD) instead of $(CC) for linking the object files Kyohei Kadota via GitGitGadget 2020-09-10 2:17 ` [PATCH v3 0/2] Fit the building tools to Plan 9 environment KADOTA, Kyohei via GitGitGadget 2020-09-10 2:17 ` [PATCH v3 1/2] Fit to Plan 9's ANSI/POSIX compatibility layer Kyohei Kadota via GitGitGadget 2020-09-10 5:13 ` Junio C Hamano 2020-09-10 2:17 ` [PATCH v3 2/2] Use $(LD) instead of $(CC) for linking the object files Kyohei Kadota via GitGitGadget 2020-09-10 5:31 ` Junio C Hamano
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: http://vger.kernel.org/majordomo-info.html * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=CAFMepcn-yWtke7eE006a5RGO6uaScWb2xZe4H5M8X4F_T4Rhbw@mail.gmail.com \ --to=lufia@lufia.org \ --cc=git@vger.kernel.org \ --cc=gitgitgadget@gmail.com \ --cc=sandals@crustytoothpaste.net \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
git@vger.kernel.org list mirror (unofficial, one of many) This inbox may be cloned and mirrored by anyone: git clone --mirror https://public-inbox.org/git git clone --mirror http://ou63pmih66umazou.onion/git git clone --mirror http://czquwvybam4bgbro.onion/git git clone --mirror http://hjrcffqmbrq6wope.onion/git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V1 git git/ https://public-inbox.org/git \ git@vger.kernel.org public-inbox-index git Example config snippet for mirrors. Newsgroups are available over NNTP: nntp://news.public-inbox.org/inbox.comp.version-control.git nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git nntp://news.gmane.io/gmane.comp.version-control.git note: .onion URLs require Tor: https://www.torproject.org/ code repositories for the project(s) associated with this inbox: https://80x24.org/mirrors/git.git AGPL code for this site: git clone https://public-inbox.org/public-inbox.git