Eric Blake wrote:
> The portability bug I am referring to is the use of double-quoted
> back-ticks containing a double quote. Some (buggy) shells require you to
> use \" instead of " inside backticks if the overall backtick expression is
> double-quoted.
Hence this statement in Posix:
Eithe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Angel Tsankov on 2/16/2009 2:26 AM:
>> There are some contexts, such as variable assignments, where double
>> quotes are not necessary.
>>
>> foo="`echo "a b"`"
>> bar=`echo "a b"`
>>
>> only the setting of bar is guaranteed to parse corre
Dave B wrote:
> Angel Tsankov wrote:
>> Eric, thanks for youy replay. If double quotes are not that
>> portable, then how am I suppose to assign the output from some
>> command to a variable when the output contains a space?
>
> Word splitting doesn't happen on assignments, so:
>
> $ var=$(echo "f
Angel Tsankov wrote:
> Eric Blake wrote:
>> According to Angel Tsankov on 2/15/2009 3:02 PM:
>>> I tried CPATH="${CPATH}${CPATH:+:}"~usr1/blah/blah. (I quote
>>> expansions just to be on the safe side, though I think home
>>> directories may not contain spaces.)
>> There are some contexts, such as
Eric Blake wrote:
> According to Angel Tsankov on 2/15/2009 3:02 PM:
>> I tried CPATH="${CPATH}${CPATH:+:}"~usr1/blah/blah. (I quote
>> expansions just to be on the safe side, though I think home
>> directories may not contain spaces.)
>
> There are some contexts, such as variable assignments, whe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Angel Tsankov on 2/15/2009 3:02 PM:
> I tried CPATH="${CPATH}${CPATH:+:}"~usr1/blah/blah. (I quote
> expansions just to be on the safe side, though I think home directories may
> not contain spaces.)
There are some contexts, such as va
On Mon, Feb 16, 2009 at 12:11 PM, Paul Jarc wrote:
> Jon Seymour wrote:
>> The manual specifies a rule for ${parameter:+word}, but not
>> ${parameter+word}.
>
> It's there, but easy to miss:
> In each of the cases below, word is subject to tilde expansion, parame-
> ter expansion, c
Jon Seymour wrote:
> The manual specifies a rule for ${parameter:+word}, but not
> ${parameter+word}.
It's there, but easy to miss:
In each of the cases below, word is subject to tilde expansion, parame-
ter expansion, command substitution, and arithmetic expansion. When
"Angel Tsankov" wrote:
> How do you know that $# is always set? And what about $...@? To what values
> are these parameters set outside any function?
$# gives the number of positional parameters. If there aren't any
positional parameters, then it's set to 0. In the man page, under
PARAMETERS
$# is the number of position parameters in the current context, so it
will always have well defined value.
Technically, $? does not have a well-defined value if there hasn't
been a previously executed foreground pipeline but in practice seems
to have the value 0, so could be used too.
$@ wouldn't
On Mon, Feb 16, 2009 at 11:44 AM, Paul Jarc wrote:
> Jon Seymour wrote:
>> On Mon, Feb 16, 2009 at 10:22 AM, Paul Jarc wrote:
>>> CPATH=${CPATH:+$CPATH:}${#+~usr1/blah/blah}
>>
>> Out of interest, how does one derive that outcome from the documented
>> behaviour of bash? That is, which expansion
Paul Jarc wrote:
> Jon Seymour wrote:
>> On Mon, Feb 16, 2009 at 10:22 AM, Paul Jarc wrote:
>>> CPATH=${CPATH:+$CPATH:}${#+~usr1/blah/blah}
>>
>> Out of interest, how does one derive that outcome from the documented
>> behaviour of bash? That is, which expansion rules are being invoked?
>
> It's
Jon Seymour wrote:
> On Mon, Feb 16, 2009 at 10:22 AM, Paul Jarc wrote:
>> Jon Seymour wrote:
>>> If the builtin echo fails it will be because the bash interpreter
>>> has suffered a catastrophic failure of some kind [ e.g. run out of
>>> memory ]. Once that has happened, all bets are off anyway.
Jon Seymour wrote:
> On Mon, Feb 16, 2009 at 10:22 AM, Paul Jarc wrote:
>> CPATH=${CPATH:+$CPATH:}${#+~usr1/blah/blah}
>
> Out of interest, how does one derive that outcome from the documented
> behaviour of bash? That is, which expansion rules are being invoked?
It's ${parameter+word}, using $#
On Mon, Feb 16, 2009 at 10:22 AM, Paul Jarc wrote:
> Jon Seymour wrote:
>> If the builtin echo fails it will be because the bash interpreter has
>> suffered a catastrophic failure of some kind [ e.g. run out of memory
>> ]. Once that has happened, all bets are off anyway.
>
> Probably true, but c
Paul Jarc wrote:
> Jon Seymour wrote:
>> If the builtin echo fails it will be because the bash interpreter has
>> suffered a catastrophic failure of some kind [ e.g. run out of memory
>> ]. Once that has happened, all bets are off anyway.
>
> Probably true, but command substitution forks a separat
Jon Seymour wrote:
> If the builtin echo fails it will be because the bash interpreter has
> suffered a catastrophic failure of some kind [ e.g. run out of memory
> ]. Once that has happened, all bets are off anyway.
Probably true, but command substitution forks a separate process, so
that can fa
Jon Seymour wrote:
> If you are willing to trade conciseness in order to eliminate use of
> builtin commands, you can use.
>
> local tmp=~usr1/blah/blah
> CPATH="${CPATH}${CPATH:+:}${tmp}"
>
> However, if you are concerned about echo failing, then you also need
> to be concerned about local faili
If you are willing to trade conciseness in order to eliminate use of
builtin commands, you can use.
local tmp=~usr1/blah/blah
CPATH="${CPATH}${CPATH:+:}${tmp}"
However, if you are concerned about echo failing, then you also need
to be concerned about local failing.
Hence:
local tmp=~usr1/
Jon Seymour wrote:
> On Mon, Feb 16, 2009 at 9:26 AM, Angel Tsankov
> wrote:
>> Jon Seymour wrote:
>>> There may be other ways to do this, but:
>>>
>>> CPATH="${CPATH}${CPATH:+:}$(echo ~usr1/blah/blah)"
>>>
>>> should work.
>>
>> Well, I'd like to avoid the use of external commands.
>>
>
> ech
On Mon, Feb 16, 2009 at 9:26 AM, Angel Tsankov wrote:
> Jon Seymour wrote:
>> There may be other ways to do this, but:
>>
>> CPATH="${CPATH}${CPATH:+:}$(echo ~usr1/blah/blah)"
>>
>> should work.
>
> Well, I'd like to avoid the use of external commands.
>
echo is a builtin, so if you are worri
Jon Seymour wrote:
> There may be other ways to do this, but:
>
> CPATH="${CPATH}${CPATH:+:}$(echo ~usr1/blah/blah)"
>
> should work.
Well, I'd like to avoid the use of external commands.
--Angel
There may be other ways to do this, but:
CPATH="${CPATH}${CPATH:+:}$(echo ~usr1/blah/blah)"
should work.
jon.
On Mon, Feb 16, 2009 at 9:02 AM, Angel Tsankov wrote:
> Chet Ramey wrote:
>> Angel Tsankov wrote:
>>> Hi,
>>>
>>> Using bash 3.2.48(1)-release, echo ""~root prints ~root instead
Chet Ramey wrote:
> Angel Tsankov wrote:
>> Hi,
>>
>> Using bash 3.2.48(1)-release, echo ""~root prints ~root instead of
>> /root. Is this the expected behaviour?
>
> Yes. The tilde is not the first character in the word. Portions of
> words to be tilde-expanded can't be quoted at all, either.
Angel Tsankov wrote:
> Hi,
>
> Using bash 3.2.48(1)-release, echo ""~root prints ~root instead of /root.
> Is this the expected behaviour?
Yes. The tilde is not the first character in the word. Portions of
words to be tilde-expanded can't be quoted at all, either.
Chet
--
``The lyf so shor
Hi,
Using bash 3.2.48(1)-release, echo ""~root prints ~root instead of /root.
Is this the expected behaviour?
Angel Tsankov
26 matches
Mail list logo
