I think the following is a bug, but I'm not really sure. I've checked the
documentation for differences between old-style command substitution (
`...` ) and new-style ( $(...) ), and couldn't see anything that related to
this problem.
*Background*
At my place of work, I use some loops with variab
On 2/27/17 11:50 AM, Martijn Dekker wrote:
> So basically you're saying that, for options without a single-letter
> equivalent, "-o" options are those that are either POSIX or that you
> think should be POSIX? But then that distinction is more political than
> technical, isn't it?
Heh. Let's just
On 2/27/17 12:57 PM, Martijn Dekker wrote:
> Op 24-02-17 om 21:20 schreef Grisha Levit:
>> XRAT C.2.5 : Special Parameters [1] specifically addresses the case of
>> ${unset_var-$*}. The following example is provided:
>>
>> set "abc" "def ghi" "jkl"
>> IFS='' # null
>> unset var
>> printf '%s\n' ${
Op 24-02-17 om 21:20 schreef Grisha Levit:
> XRAT C.2.5 : Special Parameters [1] specifically addresses the case of
> ${unset_var-$*}. The following example is provided:
>
> set "abc" "def ghi" "jkl"
> IFS='' # null
> unset var
> printf '%s\n' ${var-$*}
>
> abcdef ghijkl
>
> ..which seems to co
Op 27-02-17 om 15:32 schreef Chet Ramey:
> At the time, there were already some bash-specfic additions to
> `set -o' (braceexpand/histexpand/posix), but I wasn't interested in
> adding twenty more.
But why not? What's the advantage to users in creating a separate
category of options, seemingly bas
On 2/27/17 1:08 AM, Martijn Dekker wrote:
> It is not clear to me why bash has two separate namespaces for
> long-named shell options, handled by two separate commands.
This has come up before.
When I added `shopt' in bash-2.0 (1996), I was primarily interested in
adding a unified interface to re
