help-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-bash] Assigning builtins behavior


From: Eric Blake
Subject: Re: [Help-bash] Assigning builtins behavior
Date: Mon, 8 Jan 2018 07:07:28 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

On 01/07/2018 03:10 PM, Quentin L'Hours wrote:
> Hi,
> 
> I've always thought builtins could not have a custom parsing, however it
> seems that export/readonly/declare/local (all the builtins creating an
> assignment) are able to disable field splitting when an assignment takes
> place, why is that? I know a simple assignment disables field splitting,
> but after all that's because the grammar states it should, but doesn't
> POSIX requires all simple commands to have the same splitting behavior?

No, POSIX actually documents the notion of an "assignment context", and
builtins like export/readonly/declare/local are all examples of commands
with assignment context parsing:

http://austingroupbugs.net/view.php?id=960#c2777

> 
> bash$ foo=$(echo 1 bar=2)
> bash$ echo "$foo"
> 1 b=2

Copy-and-paste error?

> 
> This is logic, simple assignment doesn't triggers field splitting,
> that's the rule.
> 
> bash$ set a=$foo
> bash$ echo "$1"
> a=1
> 
> This is logic too, field splitting happens as expected

Or rather, 'set' has not been given assignment context parsing rules
(and doing so would probably break existing scripts).

> 
> bash$ readonly a=$foo
> bash$ echo "$a"
> 1 b=2
> 
> Why? I know simple assignment doesn't split but I would have thought
> this should still follow the simple commands arguments expansion and
> thus should do 2 assignments.

This is a case where 'readonly' has assignment context, and the parser
can easily tell up front that an assignment is being made, so field
splitting is suppressed during the assignment, as permitted by POSIX.

> I mean builtins shouldn't be able to have
> their custom parsing, if they do then they should be classified as
> keywords (like [[ ]]). What should be the POSIX way of doing things? Is
> this a bash extension?

It is a permitted (but not required) POSIX behavior.

> 
> As a side note ksh has the same behavior, but dash follows what I
> thought would be the "normal" behavior:

That's because dash has not implemented assignment context parsing,
which is also permitted by POSIX.

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]