On Tue, Feb 28, 2012 at 05:34:21PM -0800, Linda Walsh wrote:
> How can one get the same behavior as before and look up files
> relative to PATH regardless of them having a '/' in them?
What? That sounds like it WAS a bug before, and you had somehow
interpreted it as a feature. And now you're ask
On Wed, Feb 29, 2012 at 3:30 PM, Greg Wooledge wrote:
> On Tue, Feb 28, 2012 at 05:34:21PM -0800, Linda Walsh wrote:
>> How can one get the same behavior as before and look up files
>> relative to PATH regardless of them having a '/' in them?
>
> What? That sounds like it WAS a bug before, and yo
Greg Wooledge wrote:
On Tue, Feb 28, 2012 at 05:34:21PM -0800, Linda Walsh wrote:
How can one get the same behavior as before and look up files
relative to PATH regardless of them having a '/' in them?
What? That sounds like it WAS a bug before, and you had somehow
interpreted it as a feat
On Wed, Feb 29, 2012 at 11:26:06AM -0800, Linda Walsh wrote:
> Greg Wooledge wrote:
> >Any pathname that contains a / should not be subject to PATH searching.
> You are alone in this opinion -- as most application don't follow that rule.
??
> Try 'C', if you include a include file with "/", it s
On 02/29/2012 12:26 PM, Linda Walsh wrote:
>> Any pathname that contains a / should not be subject to PATH searching.
Agreed - as this behavior is _mandated_ by POSIX, for both sh(1) and for
execlp(2) and friends.
> Pathnames that *start* with '/' are called an "absolute" pathnames,
>
> while p
On 2/28/12 10:52 AM, John Kearney wrote:
> Actually this is something that still really confuses me as well.
The key is that bash doesn't do quote removal on the `string' part of the
"${param/pat/string}" expansion. The double quotes are key; quote removal
happens when the expansion is unquoted.
It isn't just the quote removal that is confusing.
The escape character is also not removed and has its special meaning.
and this also confuses me
take the following 2 cases
echo ${a:-$'\''}
'
echo "${a:-$'\''}"
bash: bad substitution: no closing `}' in "${a:-'}"
and take the foll
On 2/28/12 11:54 AM, John Kearney wrote:
> the match string and the replace string are exhibiting 2 different
> behaviors.
Yes. Quotes in the match string are handled like quotes in the %% and ##
pattern removal expansions: they quote special characters for the matcher
and are removed. The doub
On 2/28/12 12:05 PM, Steven W. Orr wrote:
>> Look consider this
>> test=teststring
>>
>>
>> echo "${test//str/""}"
>
> This makes no sense.
It does when you consider that Posix says (still) that quotes inside
the ${} must match and affect how the closing `}' is found.
--
``The lyf so short
On 2/28/12 1:04 PM, John Kearney wrote:
> bash treats replacement strings inconsistently in double quoted variable
> expansion.
Double-quoted pattern substitution.
> treated as literal because it is printed
> treated as quote char because otherwise it should hang waiting for '
Correct. It acts
Eric Blake wrote:
On 02/29/2012 12:26 PM, Linda Walsh wrote:
Any pathname that contains a / should not be subject to PATH searching.
Agreed - as this behavior is _mandated_ by POSIX, for both sh(1) and for
execlp(2) and friends.
Is it that you don't read english as a first language, or
On 2/28/12 4:28 PM, John Kearney wrote:
>
> On 02/28/2012 10:05 PM, Chet Ramey wrote:
>> On 2/28/12 12:26 PM, John Kearney wrote:
>>
>>> But that isn't how it behaves.
>>> "${test//str/""}"
>>>
>>> because str is replaced with '""' as such it is treating the double
>>> quotes as string lit
On 2/28/12 5:34 PM, John Kearney wrote:
> the outermost quotes only effect how the final value is handled.
> same as §()
${} doesn't work like $(), and it never has. That's one consequence
of backwards compatibility -- the Bourne shell didn't have $().
> having special behaviour model for that
On 02/29/2012 03:46 PM, Chet Ramey wrote:
> On 2/28/12 12:05 PM, Steven W. Orr wrote:
>
>>> Look consider this
>>> test=teststring
>>>
>>>
>>> echo "${test//str/""}"
>>
>> This makes no sense.
>
> It does when you consider that Posix says (still) that quotes inside
> the ${} must match and af
John Kearney writes:
> It isn't just the quote removal that is confusing.
>
> The escape character is also not removed and has its special meaning.
The esacape character is also a quote character, thus also subject to
quote removal.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fi
On 02/29/2012 11:53 PM, Linda Walsh wrote:
>
>
> Eric Blake wrote:
>
>> On 02/29/2012 12:26 PM, Linda Walsh wrote:
>>
Any pathname that contains a / should not be subject to PATH
searching.
>>
>> Agreed - as this behavior is _mandated_ by POSIX, for both sh(1)
>> and for execlp(2) an
On 03/01/2012 12:12 AM, Andreas Schwab wrote:
> John Kearney writes:
>
>> It isn't just the quote removal that is confusing.
>>
>> The escape character is also not removed and has its special
>> meaning.
>
> The esacape character is also a quote character, thus also subject
> to quote removal.
On 02/29/2012 11:55 PM, Chet Ramey wrote:
> On 2/28/12 4:28 PM, John Kearney wrote:
>>
>> On 02/28/2012 10:05 PM, Chet Ramey wrote:
>>> On 2/28/12 12:26 PM, John Kearney wrote:
>>>
But that isn't how it behaves.
"${test//str/""}"
because str is replaced with '""' as such
Greg Wooledge wrote:
On Wed, Feb 29, 2012 at 11:26:06AM -0800, Linda Walsh wrote:
Greg Wooledge wrote:
Any pathname that contains a / should not be subject to PATH searching.
You are alone in this opinion -- as most application don't follow that rule.
??
Try '
On Wednesday 29 February 2012 17:53:21 Linda Walsh wrote:
> Eric Blake wrote:
> > On 02/29/2012 12:26 PM, Linda Walsh wrote:
> >>> Any pathname that contains a / should not be subject to PATH searching.
> >
> > Agreed - as this behavior is _mandated_ by POSIX, for both sh(1) and for
> > execlp(2)
20 matches
Mail list logo
