bug with sed and escaping?

bug with sed and escaping?

[Dino Ruic]

Hello,

this is my first report, so I hope I can provide enough information. 
Also I'm somewhat of a beginner with zsh... Here's the thing:

As far as I've found out the zsh should not behave differently than the 
bash if I execute bash scripts. Here's a minimal example of what it does 
on my system.

Bash:
$ echo "xy" | sed -e s/^x//
y

The result is the string "y" as the sed command removes the initial x.

Zsh:
$ echo "xy" | sed -e s/^x//
zsh: no matches found: s/^x//

So this gives me an error. Zsh wants me to escape the caret (^) or I 
could wrap s/^x// in quotation marks. Either of those commands work

$ echo "xy" | sed -e "s/^x//"
$ echo "xy" | sed -e s/\^x//


If it were my script that I have to execute there, I'd change it to work 
properly. But this script is actually part of a large compiler package 
and it irks me that the zsh throws an exception while trying to execute 
some bash scripts in there. And I wouldn't want to "repair" scripts that 
actually should work.

Am I doing something wrong, here?

I tried this on multiple machines. Maybe I messed up some configuration, 
but I don't know where and why. If you need further information, please 
let me know.

Thanks in advance
Dino

Re: bug with sed and escaping?

[Peter Stephenson]

On Wed, 10 Apr 2013 11:43:02 +0200
Dino Ruic <dr@ithe.rwth-aachen.de> wrote:
> Zsh:
> $ echo "xy" | sed -e s/^x//
> zsh: no matches found: s/^x//

The "^" is doing a form of enhanced file name generation: what you've
typed means "match all files that start with 's/' and then continue with
anything that isn't 'x//'", which obviously isn't what you want.  If
you're not using the additional pattern matching features of ^, ~, #, |
and parentheses as documented in the zshexpn manual page, you can
"unsetopt extendedglob".  It's not on by default, so something in your
initialisation files is setting it.

Generally, however, you really need to decide if you actually need raw
Bourne shell stuff to work --- in which case it's possible to get zsh to
emulate it more fully, but in that case you might be better off with a
shell that does it by default, depending what it is you're trying to do
--- or if all you want is to learn how zsh works and adapt to it.  In
the latter case, quoting is the right way to go in this particular case.

(I'd actually recommend single quotes --- it'll work in this case with
double quotes, but expressions involving '^' also have a meaning to
history expansion, so single quotes are a bit safer.  This is probably
week 3 of the beginner's zsh class rather than week 1 :-).)

pws

Re: bug with sed and escaping?

[Dino Ruic]

Thanks for the quick reply. I think I didn't express myself well enough 
and I also did not understand my actual problem. Though, your reply 
pointed me in the right direction, the zsh is just fine. The Bash 
scripts that are executed have the shebang #!/bin/bash in them. That 
means they are executed using the Bash-interpreter. At least they 
should, but they weren't, that's what confused me.

Here is the very simple solution to my problem: The Bash-script is 
contained in my old .bashrc which is handed to my .zshrc with the 
source-command. Therefore the shebang in the Bash-script is ignored and 
the script is interpreted by the zsh, yielding an error... changing 
"source /path/to/bashscript.sh" to "/bin/bash /path/to/bashscript.sh" 
seems to get it done.

Sorry for the beginner's question.

Thanks.
Dino


On 04/10/2013 12:00 PM, Peter Stephenson wrote:
> On Wed, 10 Apr 2013 11:43:02 +0200
> Dino Ruic <dr@ithe.rwth-aachen.de> wrote:
>> Zsh:
>> $ echo "xy" | sed -e s/^x//
>> zsh: no matches found: s/^x//
> The "^" is doing a form of enhanced file name generation: what you've
> typed means "match all files that start with 's/' and then continue with
> anything that isn't 'x//'", which obviously isn't what you want.  If
> you're not using the additional pattern matching features of ^, ~, #, |
> and parentheses as documented in the zshexpn manual page, you can
> "unsetopt extendedglob".  It's not on by default, so something in your
> initialisation files is setting it.
>
> Generally, however, you really need to decide if you actually need raw
> Bourne shell stuff to work --- in which case it's possible to get zsh to
> emulate it more fully, but in that case you might be better off with a
> shell that does it by default, depending what it is you're trying to do
> --- or if all you want is to learn how zsh works and adapt to it.  In
> the latter case, quoting is the right way to go in this particular case.
>
> (I'd actually recommend single quotes --- it'll work in this case with
> double quotes, but expressions involving '^' also have a meaning to
> history expansion, so single quotes are a bit safer.  This is probably
> week 3 of the beginner's zsh class rather than week 1 :-).)
>
> pws