17 ms·
The shell and its crappy handling of whitespace
- mbwgh 3y agoFor filesystem operations like batch renames at least, I am usually happy with `vidir` (part of `moreutils`: https://joeyh.name/code/moreutils/ https://joeyh.name/code/moreutils/). `vidir [path]` will open an editor with the given directory as buffer contents. Editing and saving will translate to a sequence of `mv` invocations.
- seeknotfind 3y agoI would expect `suf foo.html` to return `html`
- rakoo 3y agoNote: this is an issue with sh/bash/fish/zsh, not shells in general. rc, from plan9 (http://doc.cat-v.org/plan_9/4th_edition/papers/rc http://doc.cat-v.org/plan_9/4th_edition/papers/rc), correctly has lists as a first-class data structure and none of the problems in the article happen; a list is a list, not a string split on whitespaces. See https://drewdevault.com/2023/07/31/The-rc-shell-and-whitespace.html https://drewdevault.com/2023/07/31/The-rc-shell-and-whitespa... to see the examples work out of the box as you woula naturally write them.
- ElectricalUnion 3y ago> Note: this is an issue with sh/bash/fish/zsh, not shells in general. rc (...) has lists as a first-class data structure and none of the problems in the article happen; a list is a list, not a string split on whitespaces. Not really, bash, fish and zsh all have arrays as "first-class data structures"; it's only really a problem if you really want to limit yourself to POSIX shell syntax.
- rantingdemon 3y agoOr you can use powershell . Joking aside, as a relatively newbie to the star nix world and liking it - shell scripting in Linux/Unix is broken. The object handling approach that powershell provides just seem to be a better approach.
- hn92726819 3y agoThe author claims to have 35 years of shell usage (that, I believe), but these are the arguments he uses? I'll summarize for anyone who doesn't want to waste their time: "Quote your sh variables and expansions". That's the first thing I learned and the first thing I teach about shell. Using shell wrong and then complaining about it supposedly not working is a weak argument. Let's see what he says in this article: - "$* is literally useless": no, it's used to covert arguments to a string separated by the first char in IFS. Useful pretty much only for logging, but sometimes joining strings. $@ is POSIX and should be used in all other cases. A niche feature that generally shouldn't be used isn't an issue in shell - $* and $@ are the same except when $@ is quoted: true, except in more modern shells like bash, where $@ is an array, not a specially-treated variable. I don't know who told him to use $* for 35 years, but the author should be mad at them instead - To make it work properly you have to say `for i in ; do cp "$i" /tmp; done`: wrong. cp can't distinguish arguments and flags. You must either use `./` or `cp -t /tmp -- "$i"` (or some variation). It's correct in the glob/wordsplit sense, but saying this is proper is incorrect - "And the shell doesn't have this behavior for any other sort of special character": He doesnt even mention why spaces are magic. Hint: they aren't. It's entirely controlled by IFS, which you can change. The default is space, tab, and newline. He also doesn't mention globbing, which can arguably be more disasterous. An article about wordsplitting and he doesn't even mention it once? This is at best a rant
- hn92726819 3y agoTo be clear, I think shell has problems too. But this article is poorly written. I don't think it makes sense to incorrectly use a tool and then complain about how bad it is. And to qualify your article with 35 years of experience? This just reflects that the author didnt take time to learn shell for 35 years Do yourself a favor and read Greg's entire wiki: https://mywiki.wooledge.org/BashFAQ https://mywiki.wooledge.org/BashFAQ and just learn how to use it properly, and then you can complain about how painful it is to learn or how easy it is to use incorrectly rather than how bad it is if you use it wrong.
- atoav 3y agoI know all the quoting and escaping rules there are to know and still — considering that it is a shell's job to work with text the way it is designed is just a major pain. I am grateful for all those who historically came up with the concepts and put in the work, but if anybody were to design a text interface to computers where things can be piped into other commands etc. today they could heavily improve the usability of the thing and safe thousands of collective hours wasted. And peobably like when trying to create a sucessor to email, nobody would use it.
- tpoacher 3y agoThis article is obvious bait. It has to be. You choose to expand a variable and then complain about not wanting the expansion? Or about the behaviour of clearly documented special variables doing exactly what they're supposed to instead of something another special variable does? What are they unhappy about exactly, they don't like the symbol that was chosen?? These are all things you find out within minutes of reading the manpage. (one of the best written manpages out there, in fact). Heck, this isn't even a "cannot whitespace" problem. It's expanded vs unexpanded tokens. Which is a feature of the language. Because it's text/stream based (not "despite"). 35 years of shell experience? I call bait.
- wodenokoto 3y agoJust because something is documented doesn't mean it is not crappy. I agree with the author, that just like how | aren't interpreted in `echo $myvar` neither should spaces. I also agree that `mv "$i" "$(suf "$i")" is unnecessarily cumbersome.
- tpoacher 3y agoIndeed. Which is why you should use the built-in parameter expansion provided by bash for easily removing a suffix, instead of an external program. The thing about spaces (and expansion more generally) as I understand it is this. At some point the bash designers had a choice how to represent expanded, unexpanded, and verbatim strings. One could argue that verbatim should have been the default, with expanded using single quotes, and unexpanded using double quotes, such that you would only get expansion if you really wanted it. This might have been my choice if I had designed it. I'm guessing, however, that the designers quite reasonable went for the opposite logic, which was, if you use a $ in your string, you're probably after expansion, rather than a verbatim $ symbol (and you can always escape it in the unlikely scenario that you did want a verbatim one). So presumably they chose expanded as the default because it would be the most common, leaving single quotes for verbatim instead.
- deafpolygon 3y agoPowerShell is worth looking into (and can be a viable shell on Linux).
- PaulHoule 3y agoIt is a reason to “just use Python” for scripting, or Java or C for that matter.
- 13of40 3y agoThey have powershell on those unix computers nowadays. Just sayin'.
- rcme 3y agoI-Don’t-Want-All-My-Commands-To-Be-This-Long
- 13of40 3y agoGet-Alias
- shortrounddev2 3y agoThere's aliases, and you can just hit tab to autocomplete the commands and their argument names. I find Powershell to be far more readable than bash because of its verbosity
- rcme 3y agoAliases aren’t portable
- vips7L 3y agoI don’t think I’ve ever seen a portable posix shell script. They all rely on bash-isms and gnu binary behavior
- shortrounddev2 3y agoPersonally I don't write portable shell scripts. They exist only for my own usage on my desktop. If we rely on any kind of script for deployment purposes at work, we use the scripting lang in the build system or a python script
- jks 3y agoshellcheck can remind you of most pitfalls
- hoherd 3y agoEvery time one of these "shell sucks" articles is posted I read the examples and think "shellcheck would catch that". Shellcheck is the main reason I have not migrated to zsh, or more generally it's because zsh doesn't have a syntax linter. More and more I find that confidence is one of the best goals you can have in every software and system project, and any tool or process that can increase your confidence is going to make your life easier. Shellcheck gives you that confidence when working with the shell. Never write shell code without it.
- arp242 3y agoIt should be said that many of the worst footguns shellcheck warns about simply don't apply to zsh – you don't need shellcheck to the same degree that you do with POSIX sh or bash. The first "wrong" example in this article for example (cp $i /tmp) is perfectly fine in zsh, and the complex 'mv "$i" "$(suf "$i")".jpg' is just 'mv $i $i:r.jpg' in zsh. $* and $@ are identical in zsh, and both are also arrays. There is no way to use it wrong really, and no weird '"$@" with quotes is a special case that's handled different from everything else'. Most "shell problems" people experience are "bash problems" (or "POSIX sh problems", but for many they're more or less synonymous); certainly pretty much all the problems listed in this article are. This always proves to be a controversial opinion, but I will forever keep insisting: just don't use POSIX sh or bash if it can at all be helped. You most likely don't need the portability, and installing zsh (or fish, or oil, or whatever) is easy enough in most the cases because you're the one controlling the environment.
- wpm 3y agoThat’s why it’s called bash: you gotta bash your head against the desk real hard sometimes before the damn thing does what you want.
- deleted 3y ago[deleted]
- ape4 3y agoIf only all UI applications replaced whitespace with underscores when making files. I know... that will never happen and won't help with existing files.
- JadeNB 3y agoNo, please no! Let's first figure out what it means to work with whitespace properly, then update our tools to do it. Behind-the-scenes mangling to work around flawed tools seems to be the macOS favored solution, with .DS_Store files dropped silently everywhere, and "case-insensitive but case-respecting" by default file systems, and increasingly byzantine approaches to file management so that it's harder and harder to figure out where anything is actually stored, which defeats the whole point of a Unix underlayer ….
- pasc1878 3y agoWell .DS_Stores are just used by Finder - but do show the limitations of Unix Filesystems. Where should the data they hold be stored? The macOS API is really Foundation - a layer above POSIX - if you use that then the filesystem is not that bad. It gives another solution to meta data like .DS_Store which is bundles. Bundles are an object in the Foundation API which you manipulate as one - on the filesystem they are a directory. Think of a bundle as a zipfile that you can look at using POSIX tools. The files being in odd places is for similar reasons to XDG"s attempt at cleaning up Unix. I think that the MacOS/NeXT structure predates XDG.
- thesuperbigfrog 3y ago>> Let's first figure out what it means to work with whitespace properly What does it mean to work with whitespace properly? When commands are entered at the command line and a shell is parsing, how do you distinguish between whitespace between commands, command parameters and switches, filenames that include whitespace characters, paths that include whitespace characters, etc. ? It is a difficult question that does not have good answers.
- arp242 3y ago
- shortrounddev2 3y agoPowershell solves these problems by having structured data and types and not just streams of bytes
- hnlmorg 3y agoThis isn’t related to pipes. This is related to how command lines and variables are tokenised and expanded. Zsh doesn’t have this issue, nor does most, if not all, other shells written in the last 10+ years.
- Arnavion 3y agoIt's related to pipes in the sense that if you write a pipe like `gci | % { foo $_.Name }` or `gci | % Name | bar` you won't have to worry about quoting either, because the `.Name` is a single string object and is not word split. But overall, yes the fundamental reason is that PS also does not do word-splitting on string values.
- ElectricalUnion 3y ago> because the `.Name` is a single string object File path names are bytestrings on most OSes, so you have undefined behaviour if your pipeline can't handle that.
- Arnavion 3y agoThat's irrelevant to the overall point regarding word-splitting. dotnet represents filenames as String, so there can be nothing in the pipeline that couldn't handle them. Files whose names can't be represented in String are a dotnet problem, not a PS problem.
- ElectricalUnion 3y agoI am pretty sure that if something can't be handled by a program because it's underlying language can't handle it still counts as "program can't handle the problem". "just don't mangle my filenames" is a pretty basic requirement for a universal use shell.
- vbernat 3y agoZsh does not split words by default, so you don't need to quote everything. This is the main reason I switch to Zsh instead of Bash when there I need a bit more than the base shell.
- frizlab 3y agoOoooh I did not know that. I’m so used to quoting everything I won’t stop anyway, but it’s good to know.
- pxeger1 3y agoI can't exactly remember but I think there are a few rare circumstances where you still have to quote things. Inside ${} maybe?
- tuukkah 3y agoAccording to this, it does not happen when you use variables (unless you explicitly ask for it), but it does happen on the output of the command substitution: > A command enclosed in parentheses preceded by a dollar sign, like `$(...)', or quoted with grave accents, like ``...`', is replaced with its standard output, with any trailing newlines deleted. If the substitution is not enclosed in double quotes, the output is broken into words using the IFS parameter. https://www.csse.uwa.edu.au/programming/linux/zsh-doc/zsh_15.html https://www.csse.uwa.edu.au/programming/linux/zsh-doc/zsh_15...
- vbernat 3y agoI don't think there is an exception. Zsh still applies word splitting on process substitution (I suppose this is more natural here).
- tuukkah 3y agoThe way you put it, it does sound like an exception. But what I read, it does not seem to apply on process (or any other) substitution but on the output of command substitution (see under your sibling comment).
- JadeNB 3y ago> for i in *.jpeg; do > mv "$i" $(suf "$i").jpg # two sets of quotes > done Doesn't this need another set of quotes, `mv "$i" "$(suf "$i")".jpg`, or else it'll just fail in a slightly different way when asked to `mv "bite me" bite me.jpg`?
- oneshtein 3y agoYep. $ echo $(echo "a b") a b $ echo "$(echo "a b")" a b
- stabbles 3y agoread one more sentence of the article
- mjd 3y agoThe article says that in the very next sentence.
- JadeNB 3y agoSo it does, thanks and sorry. I got so puzzled wondering what special case I was missing that would handle this correctly that I couldn't move on until I realized why what I was sure was wrong wasn't, even though, as you say, moving on would have let me realize that what I was sure was wrong was.
- mjd 3y agoHey, I do that too for the same reason. You have my sympathy, it is super embarrassing when it happens.
- mjd 3y agoBTW, regarding this: https://www.reddit.com/r/math/comments/chhtx/comment/c0smh0c/ https://www.reddit.com/r/math/comments/chhtx/comment/c0smh0c... * That article was #4 in a series. I did add a correction to article 3 the same day that 4 was published, and very soon afterward (same day, perhaps) I published a detailed followup. A few months later I added cross-links between all the articles. (See https://blog.plover.com/math/i-5.html https://blog.plover.com/math/i-5.html ) * I'm sorry I didn't reply to your email at the time. I'm not sure that I received it. But I just checked, and I did get at least two messages on the topic that I didn't reply to, one from someone named Briggs and one from someone named Barlotti. If either of these is you, I apologize. I do try to answer blog-related email.
- DrBazza 3y agoCorollary, if a developer, purposely root your ci system in a path with spaces in it to pick up these sorts of problems at build time.
- collinvandyck76 3y agothis is a great idea thank you
- SAI_Peregrinus 3y ago`Τĥιs ñåmè įß ą váĺîδ/ POSIX paτĥ/` is one I like using. If your scripts pass shellcheck, they'll handle those two directories without issue. Every byte (octet) other than 0x00 is valid in a path. Every byte other than 0x00 or / is valid in a file name. If you can't handle that, your script isn't compatible with all valid POSIX paths. That may be acceptable (e.g. you're generating all the paths in question), but isn't always.
- teo_zero 3y agoI suggest you add a trailing - (hyphen) to detect scripts unable to treat filenames separately from options.
- duskwuff 3y ago> Every byte (octet) other than 0x00 is valid in a path. I'd counter that there are a couple of differing levels of validity: 1. Printable ASCII alphanumerics, period, hyphen, underscore. Guaranteed to be portable anywhere and completely safe. 2. Safe ASCII punctuation (space, ~, $, etc). Usable on virtually all systems, likely to cause weird behavior in poorly written shell scripts. 3. Unsafe ASCII punctuation (< > : " \ | ? *). Disallowed on Windows, also likely to cause weird behavior when allowed. 4. Invalid UTF-8 sequences. Disallowed on macOS, not representable at all on Windows (which uses UTF-16 for filenames!), and will cause havoc in some programming languages like Python which assume that the filesystem is Unicode. 5. ASCII control characters (0x01 - 0x1e). Also disallowed on Windows, and you'd have to be nuts to use them even if they are supported.
- unshavedyak 3y agoFunny, i was just discussing migrating Plex files from Windows to Linux, and if it requires persisting whitespace in the filenames. My position was that "Linux" handles spaces fine, but if i can avoid dealing with escapes in filenames that would be nice. Curious to read this article when it recovers from the HN load.
- Izkata 3y agoAuto-splitting variables is for passing arguments to a command you'll be using multiple times, or that you need to change under some condition, for example: RSYNC_ARGS='--progress --human-readable --human-readable' if some_condition; then RSYNC_ARGS="$RSYNC_ARGS --exclude-from=some_file"; fi rsync $RSYNC_ARGS foo bar I can't think of a use for $* though and would guess it probably existed before $@ and is still there just for backwards compatibility.
- stabbles 3y agoThat's equally problematic... '--progress=yes please' with whitespace runs into problems. In Bash you can use arrays though: args+=('--progress=yes please')
- Izkata 3y agoSee last point about backwards compatibility. Arrays did come later. The array style probably should always be used nowadays (don't forget you also need to insert it into the command like ${args[@]}), but I learned before it was common (possibly before it was a thing, I'm having trouble finding exactly when basic arrays were added to bash) so I still use the string style when I know I won't need it.
- jprete 3y agoI think whitespace handling is a problem, but not the only one. Shell data structures are awful and confusing, so best avoided. Error handling is also subpar, requiring boilerplate for every reasonable error situation. And there’s a constant need to be careful about stdout va stderr and how exactly a function returns data. I find moving to even Python to be an inadequate answer, because the shell does two crucial things very very well - it manipulates the filesystem and runs commands in their most native format. And even Python is very cumbersome at those two tasks. But sometimes you need good data structures/execution flow control, and good filesystem/command control, at the same time. Intuitive, consistent, predictable whitespace handling would fix a lot of shell scripting problems, though. (I haven’t given Powershell a serious shot, maybe I should.)
- massysett 3y agoTake a look at Oil Shell? https://www.oilshell.org/ https://www.oilshell.org/
- svilen_dobrev 3y agolike, the || && operators having same precedence.. and other inconsistencies, i.e. how to pass "a*" down as parameter.. btw csh/tcsh "" quoting rules are atrocious, avoid it..
- pram 3y agoI use declare in a lot of my bash scripts for associative arrays and some other stuff. It can make scripts easier to read/reason about IMO. Something useful to learn if you’ve never heard of it. https://linuxhint.com/bash_declare_command/ https://linuxhint.com/bash_declare_command/
- pjmlp 3y ago> I find moving to even Python to be an inadequate answer, because the shell does two crucial things very very well - it manipulates the filesystem and runs commands in their most native format. And even Python is very cumbersome at those two tasks. Thankfully Perl exists.
- WorldMaker 3y ago
- pluto_modadic 3y agothis reminds me that zsh auto-escaping \$ and \& on basically all my shells messes up pasting curl commands and other payloads... or doesn't and still looks them up in weird subshells. no such problems in bash.
- arp242 3y ago> zsh auto-escaping \$ and \& on basically all my shells messes up pasting curl commands This must be something you configured, or added in a plugin or something, because it's not the default behaviour, and AFAIK it's also not a simple setting.
- diarrhea 3y agoAs far as I remember, if you put quote(s) first, then paste into them, this doesn’t happen. That would then be strictly better, as zsh catches the unquoted special characters, preventing disaster, but doesn’t interfere if quoting is in place.
- Brian_K_White 3y agoMaking the assumption that I'm not intentionally pasting a command is wrong. So if it doesn't do that by default, that's good.
- kergonath 3y agoThat’s very weird. I paste commands all the time without any issue like that. Is it a setting you changed, or some strange behaviour of your terminal emulator?
- YesThatTom2 3y ago> I think what bugs me most about this problem in the shell is that it's so uncharacteristic if the Bell Labs people to have made such an unforced error. Bell Labs fixed it with the shell called “tc”. They can’t be blamed that you ignored it. https://www.scs.stanford.edu/nyu/04fa/sched/readings/rc.pdf https://www.scs.stanford.edu/nyu/04fa/sched/readings/rc.pdf
- mjd 3y agoI didn't miss it. I was an rc user for many years.
- ajross 3y ago> Even if [parsing command arguments via whitespace boundaries] was a simple or reasonable choice to make in the beginning, at some point around 1979 Steve Bourne had a clear opportunity to realize he had made a mistake. He introduced $* and must shortly therefter have discovered that it wasn't useful. This should have gotten him thinking. First off, no, that's not a bug. The alternative is some variant of "here's a data structure to hold the list of arguments you need to manipulate manually". And that's how program execution works in "real programming language" environments (even things like PowerShell). And it sucks, which is why we all continue to use the Bourne shell after four decades to solve these problems. What we really want is "here's a string to execute just like I typed it; go!". Sure, that's not what we think we want. And we might convince ourselves that mishandling based on that metaphor is a bad thing and write too-smart-for-our-own-good blog posts about it to show how smart we are. But no, we don't want that. We want shell. If we didn't want shell, we wouldn't write shell scripts. And yet, here we are. Again, four decades outweighs any amount of pontification in a blog post. If you aren't willing to start from a perspective of why this system remains so successful, you're probably not bringing as much insight to the problem as you think you are.
- yyyk 3y ago>Again, four decades outweighs any amount of pontification in a blog post. Many more people used MS-DOS/Windows during that time. >And it sucks, which is why we all continue to use the Bourne shell after four decades to solve these problems. >But no, we don't want that. We want shell. People continue to use Linux and Unix and interactive shell for good reasons. Shell as scripting shell is there simply because it's available, a form of Stockholm Syndrome I guess.
- ajross 3y ago> Many more people used MS-DOS/Windows during that time. But not since. No one writes new win16 or DOS or batch files. People still write shell scripts. Every day. Despite the existence of a deluge of supposedly better solutions. And if your explanation for why shell is so terrible doesn't have a way to explain that, I argue it's an incorrect explanation. "We all have Stockholm Syndrome" is just ridiculous, btw.
- PaulDavisThe1st 3y ago> I think what bugs me most about this problem in the shell is that it's so uncharacteristic if the Bell Labs people to have made such an unforced error. They got so many things right, why not this? All it takes to understand it is that it took a while for anyone to consider that spaces in filenames was (or might be) a thing. I don't know that this is true, but having started on Unix about the same time as the author of TFA, I know that I found it quite disorienting when I first started interacting with Windows/macOS users who regularly used spaces in their filenames and thought nothing of it. I suspect this wasn't an "error" as much as just a failure to grok the pretty basic idea that "bite me.jpg" is an entirely valid filename, and maybe more useful than "biteme.jpg" or "bite_me.jpg"
- Brian_K_White 3y agoand steve's & edy's taxes.xls and 10" deck.doc and Surprise!.mov and... all the other shell active characters which are otherwise just normal characters that normal people will want to use. If it's on the keyboard, they expect to be able to use it.
- teo_zero 3y agoI disagree. There's also a Return key, but you don't want CR in file names. A file name is not a document's title.
- yetihehe 3y ago> There's also a Return key, but you don't want CR in file names. I don't want CR in file names, but someone somewhere will want it for some strange formatting reason (I've seen things). > A file name is not a document's title. You say that, other people have other ideas. When you let non-technical people use your too technical system, it will crash. --- A software tester walks into a bar. Runs into a bar. Crawls into a bar. Dances into a bar. Flies into a bar. Jumps into a bar. And orders: a beer. 2 beers. 0 beers. 99999999 beers. a lizard in a beer glass. -1 beer. "qwertyuiop" beers. Testing complete. A real customer walks into the bar and asks where the bathroom is. The bar goes up in flames.
- dspillett 3y agoAllowing spaces in filenames where command invocations are pure text streams⁰ is the problem IMO, though one made several distinct times¹, and one that would be made again if all past occurrences were somehow removed from history, so suggesting we fix things that way is pointless as a way forward. Requiring filenames to be quotes if they contain spaces, or optionally otherwise, would help – similar to CSV values with commas in. Though this opens up other issues: what about filenames containing quotes, and when nesting calls² the question of what part does the unpacking becomes a complex question without explicit structure. And to be honest we have enough trouble with clients sending us malformed CSV with unquoted commas that I can confidently state this wouldn't work either. And you can't trust users to follow instructions, even internal users, where the limitation might be an issue. If you put a simple helper tool together and say “it won't work with spaces in filenames”, either it becomes a high priority ticket that the thing you jammed together as a favour doesn't work with spaces, or you get so sick or responding to problem reports that turn out to be due to the matter that you spend time fixing it up anyway. </rant> -- [0] for systems that pass structured data, such as powershell, spaces are handled fine, though that would be a lot of work to retrofit into shells & utilities with a generally useful level of conformance [1] like the convergent evolution of wings in pterodactyls/birds/bats or crab-like features all over the place [2] for instance ssh to run a complex command line involving sudo
- liendolucas 3y agoAh, double quotes handling can be another nightmare as well, can't make this work: function backup { local SOURCE=$1 local DESTINATION=$2 local ID_RSA=$3 # VALID_SSH is hard-coded for testing. local VALID_SSH="yes" local REMOTE_SHELL="" if [[ "${VALID_SSH}" == "yes" ]]; then REMOTE_SHELL='-e "ssh -i '${ID_RSA}'"' fi rsync -av \ --no-perms \ --links \ $(if [[ "${VALID_SSH}" == "yes" ]]; then echo "${REMOTE_SHELL}"; fi) \ "${SOURCE}" "${DESTINATION}" } As it is when calling the function: backup "." "backup@redstar.local:" "id_rsa" rsync complains with: Missing trailing-" in remote-shell command. rsync error: syntax or usage error (code 1) at main.c(438) [sender=3.1.3] But if I echo the `rsync` instead of calling it, its output is perfectly valid it actually runs as expected: rsync -av --no-perms --links -e "ssh -i id_rsa" . backup@redstar.local: Been fiddling yesterday and today with no luck, it must be something very subtle. Tried a bunch of different things from SO suggestions but none seem to work. Meh.
- o11c 3y agoAs a rule, `printf %q` or `${var@Q}` are very useful when building up quoted command strings. But your main problem is that `REMOTE_SHELL` is a string, when you need an array. Though I suppose you could make it a string if you used `eval` around its whole use.
- fragmede 3y agoHave you tried REMOTE_SHELL="-e \"ssh -i ${ID_RSA}\"" already?
- liendolucas 3y agoYup, same result. I've tried many small variations around the escaping of the double quotes, all with the same result. I haven't kept all of them but definitely tried your approach.
- fragmede 3y agoOh it's the $(if [[ "${VALID_SSH}" == "yes" ]]; then echo "${REMOTE_SHELL}"; fi) \ Change that to $(if [[ "${VALID_SSH}" == "yes" ]]; then echo ${REMOTE_SHELL}; fi) \ and have REMOTE_SHELL="-e \"ssh -i '${ID_RSA}'\""
- spc476 3y agoHow about using non-break spaces in filenames? It worked when I last tried it (https://boston.conman.org/2018/02/28.2 https://boston.conman.org/2018/02/28.2).