9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Kurt H Maier <khm@sciops.net>
To: 9front@9front.org
Subject: Re: [9front] [PATCH] awk(1): quote argument for -v option
Date: Tue, 29 Nov 2022 08:43:43 -0800	[thread overview]
Message-ID: <Y4Y2vxMOR7sJv6w7@wopr> (raw)
In-Reply-To: <2f69e1e8-907b-59b4-7249-75a4435d9041@posixcafe.org>

On Tue, Nov 29, 2022 at 09:28:04AM -0700, Jacob Moody wrote:
> On 11/29/22 09:24, Sigrid Solveig Hafl�nud�ttir wrote:
> > Quoth Kurt H Maier <khm@sciops.net>:
> >> On Tue, Nov 29, 2022 at 01:10:26PM +0100, Anders Damsgaard wrote:
> >>> Dear all,
> >>>
> >>> Running awk from rc, I found that I need to quote the arguments to awk's
> >>> -v option, as in:
> >>>
> >>> 	awk -v 'myvar=asdf' 'BEGIN{print myvar}'
> >>>
> >>> However, the awk man page specifies this without quotes as "awk -v
> >>> myvar=asdf".  I now realize that it will not work without quotes because
> >>> rc tries to interpret the assignment operator.
> >>>
> >>> Is this just a beginner mistake, being used to unix behavior, or worth
> >>> documenting as in the patch below?
> >>>
> >>> Thanks, Anders
> >>
> >> I guess I'll be that guy again
> >>
> >> I know that the quoting quirk is a characteristic of rc and not whatever
> >> other environment one might conceivably use to launch awk.  I get that
> >> under most unix shells this is a non-issue.  However, the quoted variant
> >> also works fine in e.g. bash and ksh and so forth.  It's all the same to
> >> awk.
> >>
> >> I submit as my actual argument that having documentation containing
> >> examples which, when copied and pasted into the primary UI of the
> >> project, do not work, is bad form.  People read man pages to learn how
> >> to use shit, not to get a sense of the general aesthetic of a given
> >> command were we to run it on v7 Unix.  The shit we say should work
> >> should work.  
> >>
> >> I vote the patch goes in.
> >>
> >> khm
> > 
> > Wasn't there a patch somewhere for Plan 9 Port(??) that made the
> > quoting a bit more relaxed when NOT specifying env vars?  I'd be more
> > inclined to accept non-quoted variant in parameters.  Having to quote
> > those is annoying, I want the computer to figure out what I'm doing,
> > not to baby-sit rc.
> > 
> 
> 
> That there was, I believe it came with the work that was done in rewriting
> the parser away from yacc. I would second this change.
> 

previously discussed in the thread 'new rc parser: do we want it?' in
this mailing list.

also related: https://www.mail-archive.com/9fans@9fans.net/msg36493.html

khm

  reply	other threads:[~2022-11-29 16:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-29 12:10 Anders Damsgaard
2022-11-29 13:47 ` qwx
2022-11-29 14:52 ` Stanley Lieber
2022-11-29 15:14 ` Kurt H Maier
2022-11-29 15:22   ` Stanley Lieber
2022-11-29 16:24   ` Sigrid Solveig Haflínudóttir
2022-11-29 16:28     ` Jacob Moody
2022-11-29 16:43       ` Kurt H Maier [this message]
2022-11-29 19:06         ` Stanley Lieber
2022-11-29 19:52           ` Stanley Lieber

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

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Y4Y2vxMOR7sJv6w7@wopr \
    --to=khm@sciops.net \
    --cc=9front@9front.org \
    /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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).