9front - general discussion about 9front
 help / color / mirror / Atom feed
From: Jacob Moody <moody@mail.posixcafe.org>
To: 9front@9front.org
Subject: Re: [9front] [PATCH] awk(1): quote argument for -v option
Date: Tue, 29 Nov 2022 09:28:04 -0700	[thread overview]
Message-ID: <2f69e1e8-907b-59b4-7249-75a4435d9041@posixcafe.org> (raw)
In-Reply-To: <E3E6A3A8A51845ADD0777E3FBBDC1641@ftrv.se>

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.


  reply	other threads:[~2022-11-29 16:31 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 [this message]
2022-11-29 16:43       ` Kurt H Maier
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=2f69e1e8-907b-59b4-7249-75a4435d9041@posixcafe.org \
    --to=moody@mail.posixcafe.org \
    --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).