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
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.
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 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
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 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 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
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 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
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 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.
On 2/28/12 5:49 PM, John Kearney wrote:
> On 02/28/2012 11:44 PM, Chet Ramey wrote:
>> echo "$(echo '$bar')"
>
> actually these both output the same in bash
> echo "$(echo '$bar')"
> echo $(echo '$bar')
Sure: the outer quotes don't affect the command between the parens. Not
only is it a new quot
On 02/28/2012 11:23 PM, Chet Ramey wrote:
> On 2/28/12 5:18 PM, John Kearney wrote:
>> On 02/28/2012 11:07 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
On 02/28/2012 11:44 PM, Chet Ramey wrote:
> echo "$(echo '$bar')"
actually these both output the same in bash
echo "$(echo '$bar')"
echo $(echo '$bar')
On 2/28/12 5:30 PM, Maarten Billemont wrote:
>>> 1${A:-B}2
>>>
>>> Logically for consistancy having double quotes at position 1 and 2
>>> should have no effect on how you treat string B.
>>
>> Maybe, but that's not how things work in practice. Should the following
>> expansions output the same th
On 02/28/2012 11:23 PM, Chet Ramey wrote:
> On 2/28/12 5:18 PM, John Kearney wrote:
>> On 02/28/2012 11:07 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
On 28 Feb 2012, at 23:23, Chet Ramey wrote:
> On 2/28/12 5:18 PM, John Kearney wrote:
>> On 02/28/2012 11:07 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 i
On 2/28/12 5:18 PM, John Kearney wrote:
> On 02/28/2012 11:07 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/""}"
>
>
On 02/28/2012 11:15 PM, Chet Ramey wrote:
> On 2/28/12 5:07 PM, Chet Ramey wrote:
>
>>> yhea but I think the point is that the current behavior is useless.
>>> there is no case where I want a " to be printed and start a double
>>> quoted string? and thats the current behavior.
>>>
>>>
>>> Not so i
On 02/28/2012 11:07 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 i
On 2/28/12 5:07 PM, Chet Ramey wrote:
>> yhea but I think the point is that the current behavior is useless.
>> there is no case where I want a " to be printed and start a double
>> quoted string? and thats the current behavior.
>>
>>
>> Not so important how you treat it just need to pick 1. then
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 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 literals.
>>
>> however at the same time these litera
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 literals.
>
> however at the same time these literal double quotes escape/quote a
> single quote betwee
John Kearney wrote:
> Eric Blake wrote:
> >> [ "${test}" = "${test//"'"/"'"}" ] || exit 999
> >
> > exit 999 is pointless. It is the same as exit 231 on some shells,
> > and according to POSIX, it is allowed to be a syntax error in other
> > shells.
>
> I was going for || exit "Doomsday" i,e. 666
On 02/28/2012 07:00 PM, Dan Douglas wrote:
> On Tuesday, February 28, 2012 06:52:13 PM John Kearney wrote:
>> On 02/28/2012 06:43 PM, Dan Douglas wrote:
>>> On Tuesday, February 28, 2012 06:38:22 PM John Kearney wrote:
On 02/28/2012 06:31 PM, Dan Douglas wrote:
> On Tuesday, February 28, 2
On 28 Feb 2012, at 18:52, John Kearney wrote:
> On 02/28/2012 06:43 PM, Dan Douglas wrote:
>> On Tuesday, February 28, 2012 06:38:22 PM John Kearney wrote:
>>> On 02/28/2012 06:31 PM, Dan Douglas wrote:
On Tuesday, February 28, 2012 05:53:32 PM Roman Rakus wrote:
> On 02/28/2012 05:49 PM,
On 02/28/2012 06:52 PM, John Kearney wrote:
> On 02/28/2012 06:43 PM, Dan Douglas wrote:
>> On Tuesday, February 28, 2012 06:38:22 PM John Kearney wrote:
>>> On 02/28/2012 06:31 PM, Dan Douglas wrote:
On Tuesday, February 28, 2012 05:53:32 PM Roman Rakus wrote:
> On 02/28/2012 05:49 PM, Gr
On Tuesday, February 28, 2012 06:52:13 PM John Kearney wrote:
> On 02/28/2012 06:43 PM, Dan Douglas wrote:
> > On Tuesday, February 28, 2012 06:38:22 PM John Kearney wrote:
> >> On 02/28/2012 06:31 PM, Dan Douglas wrote:
> >>> On Tuesday, February 28, 2012 05:53:32 PM Roman Rakus wrote:
> On 0
On 02/28/2012 06:43 PM, Dan Douglas wrote:
> On Tuesday, February 28, 2012 06:38:22 PM John Kearney wrote:
>> On 02/28/2012 06:31 PM, Dan Douglas wrote:
>>> On Tuesday, February 28, 2012 05:53:32 PM Roman Rakus wrote:
On 02/28/2012 05:49 PM, Greg Wooledge wrote:
> On Tue, Feb 28, 2012 at 0
On Tuesday, February 28, 2012 06:38:22 PM John Kearney wrote:
> On 02/28/2012 06:31 PM, Dan Douglas wrote:
> > On Tuesday, February 28, 2012 05:53:32 PM Roman Rakus wrote:
> >> On 02/28/2012 05:49 PM, Greg Wooledge wrote:
> >>> On Tue, Feb 28, 2012 at 05:36:47PM +0100, Roman Rakus wrote:
> And
On 02/28/2012 06:31 PM, Dan Douglas wrote:
> On Tuesday, February 28, 2012 05:53:32 PM Roman Rakus wrote:
>> On 02/28/2012 05:49 PM, Greg Wooledge wrote:
>>> On Tue, Feb 28, 2012 at 05:36:47PM +0100, Roman Rakus wrote:
And that means, there isn't way to substitute "something" to
' (single
On Tuesday, February 28, 2012 05:53:32 PM Roman Rakus wrote:
> On 02/28/2012 05:49 PM, Greg Wooledge wrote:
> > On Tue, Feb 28, 2012 at 05:36:47PM +0100, Roman Rakus wrote:
> >> And that means, there isn't way to substitute "something" to ' (single
> >> quote) when you want to not perform word spli
On 02/28/2012 06:16 PM, Eric Blake wrote:
> On 02/28/2012 09:54 AM, John Kearney wrote:
>> On 02/28/2012 05:22 PM, Roman Rakus wrote:
>>> On 02/28/2012 05:10 PM, John Kearney wrote:
wrap it with single quotes and globally replace all single
quotes in the string with '\''
>>> single quote
On 02/28/2012 06:05 PM, Steven W. Orr wrote:
> On 2/28/2012 11:54 AM, John Kearney wrote:
>> On 02/28/2012 05:22 PM, Roman Rakus wrote:
>>> On 02/28/2012 05:10 PM, John Kearney wrote:
wrap it with single quotes and globally replace all single
quotes in the string with '\''
>>> single quot
On 02/28/2012 09:54 AM, John Kearney wrote:
> On 02/28/2012 05:22 PM, Roman Rakus wrote:
>> On 02/28/2012 05:10 PM, John Kearney wrote:
>>> wrap it with single quotes and globally replace all single quotes
>>> in the string with '\''
>> single quote and slash have special meaning so they have to be
On 2/28/2012 11:54 AM, John Kearney wrote:
On 02/28/2012 05:22 PM, Roman Rakus wrote:
On 02/28/2012 05:10 PM, John Kearney wrote:
wrap it with single quotes and globally replace all single quotes
in the string with '\''
single quote and slash have special meaning so they have to be
escaped, th
On 02/28/2012 05:22 PM, Roman Rakus wrote:
> On 02/28/2012 05:10 PM, John Kearney wrote:
>> wrap it with single quotes and globally replace all single quotes
>> in the string with '\''
> single quote and slash have special meaning so they have to be
> escaped, that's it. \'${var//\'/\\\'}\' it is n
On 02/28/2012 05:49 PM, Greg Wooledge wrote:
On Tue, Feb 28, 2012 at 05:36:47PM +0100, Roman Rakus wrote:
And that means, there isn't way to substitute "something" to ' (single
quote) when you want to not perform word splitting. I would consider it
as a bug.
imadev:~$ q=\'
imadev:~$ input="foos
On Tue, Feb 28, 2012 at 05:36:47PM +0100, Roman Rakus wrote:
> And that means, there isn't way to substitute "something" to ' (single
> quote) when you want to not perform word splitting. I would consider it
> as a bug.
imadev:~$ q=\'
imadev:~$ input="foosomethingbar"
imadev:~$ echo "${input//so
On 02/28/2012 05:22 PM, Roman Rakus wrote:
On 02/28/2012 05:10 PM, John Kearney wrote:
wrap it with single quotes and globally replace all single quotes in the
string with '\''
single quote and slash have special meaning so they have to be
escaped, that's it.
\'${var//\'/\\\'}\'
it is not quot
On 02/28/2012 05:10 PM, John Kearney wrote:
wrap it with single quotes and globally replace all single quotes in the
string with '\''
single quote and slash have special meaning so they have to be escaped,
that's it.
\'${var//\'/\\\'}\'
it is not quoted, so it undergoes word splitting. To avoid
On Tue, Feb 28, 2012 at 05:10:40PM +0100, John Kearney wrote:
> so for the test case the goal is to take a string like
> kljlksdjflsd'jkjkljl
> wrap it with single quotes and globally replace all single quotes in the
> string with '\''
Is this an SQL thing? Maybe you'd be better off using a langu
this all started with a wish to single quote a variable. Doesn't matter
why I have multiple solutions to that now.
But it it an interesting problem for exploring how escaping works in
variable expansion.
so for the test case the goal is to take a string like
kljlksdjflsd'jkjkljl
wrap it with sing
On Tue, Feb 28, 2012 at 04:52:48PM +0100, John Kearney wrote:
> The standard work around you see is
> echo -n \'${1//\'/\'\\\'\'}\'" "
> but its not the same thing
Workaround for what? Not the same thing as what? What is this pile
of punctuation attempting to do?
> # why does thi
Actually this is something that still really confuses me as well.
In the end I gave up and just did this.
local LName="'\\''"
echo -n "'${1//"'"/${LName}}' "
I still don't really understand why this wont work
echo -n "'${1//"'"/"'\''"}' "
On 02/28/2012 02:36 PM, Chet Ramey wrote:
On 2/28/12 4:17 AM, lhun...@lyndir.com wrote:
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: darwin11.2.0
Compiler: /Developer/usr/bin/clang
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYP
On 2/28/12 4:17 AM, lhun...@lyndir.com wrote:
> Configuration Information [Automatically generated, do not change]:
> Machine: i386
> OS: darwin11.2.0
> Compiler: /Developer/usr/bin/clang
> Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
> -DCONF_OSTYPE='darwin11.2.0' -DCONF_MACHTYPE=
On 02/28/2012 10:17 AM, lhun...@lyndir.com wrote:
Configuration Information [Automatically generated, do not change]:
Machine: i386
OS: darwin11.2.0
Compiler: /Developer/usr/bin/clang
Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i386'
-DCONF_OSTYPE='darwin11.2.0' -DCONF_MACHTYPE='i386-
49 matches
Mail list logo
