* bug with sed and escaping? @ 2013-04-10 9:43 Dino Ruic 2013-04-10 10:00 ` Peter Stephenson 0 siblings, 1 reply; 3+ messages in thread From: Dino Ruic @ 2013-04-10 9:43 UTC (permalink / raw) To: zsh-workers 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: bug with sed and escaping? 2013-04-10 9:43 bug with sed and escaping? Dino Ruic @ 2013-04-10 10:00 ` Peter Stephenson 2013-04-10 11:06 ` Dino Ruic 0 siblings, 1 reply; 3+ messages in thread From: Peter Stephenson @ 2013-04-10 10:00 UTC (permalink / raw) To: Dino Ruic, zsh-workers 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: bug with sed and escaping? 2013-04-10 10:00 ` Peter Stephenson @ 2013-04-10 11:06 ` Dino Ruic 0 siblings, 0 replies; 3+ messages in thread From: Dino Ruic @ 2013-04-10 11:06 UTC (permalink / raw) To: Peter Stephenson, zsh-workers 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-04-10 11:06 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2013-04-10 9:43 bug with sed and escaping? Dino Ruic 2013-04-10 10:00 ` Peter Stephenson 2013-04-10 11:06 ` Dino Ruic
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).