-1

Is there an environmental setting that makes pasting text into Terminal work differently from typing it in directly?

I reported this as a bug, but maybe there's some environmental setting.  After the first failure, I put the command in a script to send them as a demo, but it worked when I ran the script.

The command is

echo "ΕΡΤΥΙΟΚΗΑΖΧΒΝΜ" | tr [:upper:] [:lower:]

The string is Greek letters typed with the keyboard set to Greek.  Behavior is the same whether I use the keys and fingers or the Keyboard Viewer and mouse.

locale is en_US.UTF-8 and TextEdit is set to always use UTF-8. I put the command in TextEdit, copied it to clipboard, and pasted into Terminal (with stdin containing the Greek string). Result:

zsh: no matches found: [:upper:]

If I swap the classes, I get

zsh: no matches found: [:lower:]

If I save the file from TextEdit, give it a chmod 700, and run it, it does what it should, no error message.

If I change the command to convert Greek to Latin with

echo "ΕΡΤΥΙΟΚΗΑΖΧΒΝΜ" | tr "ΕΡΤΥΙΟΚΗΑΖΧΒΝΜ" "EPTYIOKHAZXBNM"

(instead of using classes), then it works pasted or in script.

If I type echo "" | od -xc and paste the Greek between the quote marks, I see that the characters are not ASCII. So Paste from clipboard must be doing something other than changing the characters.

NOTES:

(1) the tr command fails only when pasted and it contains neither = nor ?, so escaping those is not a solution, and this is this is not a duplicate of zsh: no matches found

(2) It's plausible that zsh might treat [:xxx:] differently from bash, but what we have here is zsh/Terminal treating pasted text differently from typed in text.

Improve this question
15
  • 2
    You need to put quotes around [:upper:] and [:lower:]. Sequences in square brackets are shell wildcard expressions. bash ignores this if there are no matching filenames, but zsh throws an error. Use moar quotes! See this and this.
    – Gordon Davisson
    Commented Mar 6, 2022 at 19:05
  • In the script, I did not add quotes, and it still worked. It also worked when I typed it in instead of pasting (again without quotes). In other words, the SAME character string behaved differently when pasted in.
    – WGroleau
    Commented Mar 6, 2022 at 19:45
  • 2
    1) Did you try quoting the arguments to tr to see if the error goes away (hint: it will)? 2) ? and [ ] are both wildcards, so the same principles apply to both. Also, the other previous Q I linked is specifically about [ ] causing this error. 3) The script version is probably running under bash instead of zsh; as for why it works differently with copy&paste, there must be some other difference but I can't tell from here what it might be. C'mon, dude, show some initiative in figuring things out for yourself -- I'm not going to hold your hand every step of the way!
    – Gordon Davisson
    Commented Mar 6, 2022 at 20:42
  • I'll give that a try, but with no bang line in the script, it should run with the default shell, not with bash. Note that when the command is typed in to zsh, also without quotes, it worked.
    – WGroleau
    Commented Mar 6, 2022 at 20:54
  • 2
    If there is no bang line, scripts are executed by /bin/sh. This is standard behavior (and logical if you think of it, unless you want to introduce surprising errors if a user has the default shell set to csh for instance).
    – nohillside ♦
    Commented Mar 6, 2022 at 21:13

1 Answer 1

Reset to default
2

No, there is no environmental quick fix to strip all possible characters from your pasteboard that could cause issues when not escaped and pasted into the zsh shell.

You will want to be careful about character sets, run shellcheck on your scripts to fix them and be careful when pasting.

All manner of things that look normal to someone from bash Experience can and will trip you up with zsh - enough that switching back to bash might be the quick fix in your case.

Improve this answer
1
  • The "quick fix" is obviously to not paste things that don't work in zsh. And I usually write scripts with bang lines. this was just a "quick & dirty" to demo what appeared to be a bug. I can't agree with the decision to run an "unbanged" script in bash "to avoid surprises" when obviously, this did NOT avoid the surprise.
    – WGroleau
    Commented Mar 7, 2022 at 1:30

Not the answer you're looking for? Browse other questions tagged .