Now I use lowercase and underscores everywhere.
This is the best for tab completion, altho I prefer hyphens visually
I prefer lowercase with hyphens, but I’m transitioning into a team that does everything camelCase, which is the second best case, but I still strongly dislike it.
Hyphens > underscores for filenames because all web standards prefer hyphens so if you ever want to network your files its a much smoother experience!
This is what I need, an explicit reason that makes one choice better than another. If hyphens make for a smoother experience, then I’ll reconsider my default behavior.
Thanks for pointing out this benefit.
SameHereBrother.
deleted by creator
not sure why the default behavior is this:
file\ name\ with\ a\ bunch\ of\ spacesinstead of this:
"file name with a bunch of spaces"but you can just press
"before pressing tab to auto-complete, and it will use the 2nd formBecause quoting requires token expansion (e.g. ~ to /home/you). Escaping gives you a much shorter path in that case.
That said I’m with you, full quoted paths read better to me.
You can use variables in
"like so:cd "$HOME/Desktop".Maybe this helps?
I mean, at least in Bash tools like
lsdo use quotes by default:$ ls filename_without_space 'filename with space'But yeah, tab expansion uses backslashes, sadly.
Are you typing the whole filename by hand? Tab expansion exists, you know?
If it fucking works…
Sometimes it does. But not always.
Zsh changed my life, but I still hate escape chars in my command lines for readability reasons
whitespaceIsTheEnemyThe number of keystrokes needed to type an underscore is the same that you need to type backslash space, so I don’t see how underscores are in improvement
the struggle between spaces in filenames look cute and oh fuck what’s the code to reference a space in a filename in terminal?
Just put the whole thing in quotes. You might have to escape extra sets of quotes, usually with a backslash.
If you intend on using that with tab completions, you will have extra work to do.
Some shells put the path in quotes automatically as you attempt to complete anything with spaces in it.
Yeah, just need to set it up correctly.
Or you can also put a
\in front of the space
“_” to the rescue
I very intentionally have all my code in
Personal Projects 🥰andWork Projects 🏦directories so I can find bugs in the handling of file paths.Now I’m imagining a shell that looks iteratively through arguments to find where quotes would make total sense
$ ls my victims.ods $ wipe -f my victims.ods --thoroughSo the shell would go like
wipe→ command name found, ok-f→ no file in the current directory starts with that, skipmy→ matches a file, keep in memory…my victims.ods→ full match, but missing quotes!- Prompt user:
Filename "my victims.ods" found without quotes. Choose: [a]dd quotes this time [A]lways add quotes (dangerous) [n]o quotes today please [N]ever offer adding quotes again [t]ell me what could possibly go wrong when I choose to always add quotes [P]unch the person who proposed this featureFor interactive use, tab-completion essentially makes this a non-issue, because shells add escaping in the appropriate places.
For scripting, where spaces are harder to deal with, unfortunately there’s just not much you can do; your two options are basically to learn all of your particular shell’s patterns for dealing with whitespace in filenames, or only write scripts in something other than a POSIX shell.
Scripting isn’t the issue, but for tab completion: the boundary is often at a space or parenthesis so that you need to type the backslash + char to continue tabbing to completion
Believe me, whitespace-correct scripting is absolutely an issue.
You’re right that it’s annoying when filenames diverge right at a character that must be escaped.
If your code is written well, it shouldn’t matter.
They’re annoying to deal with when interactively using command-line shells, especially so when pasting unquoted and unescaped file paths, doubly especially so with Bash where parameter expansion makes no goddamn sense if you know at least one other programming language
Example of how parameter expansion matters?
Generally if you are pasting file paths there is a better way to do that. Use find with exec, or xargs, or a for loop. Or, get the list in Vim and escape (quote) every line at once. Unless you have double quotes in the filename too (which is actually a crazy thing) it shouldn’t be a big deal.
Expansion matters because using parameters without quotes automatically splits words, and IIRC a quoted array parameter can still be split into its members — as opposed to Zsh, where word splitting doesn’t happen unprompted and quoted array parameters are flattened into a single string.
Generally if I want to run
$HOME/random executable with spaces.exethrough Wine in a terminal I copy the path in Dolphin (CTRL+SHIFT+C, or CTRL+ALT+C idr) and paste it, within quotes if needed (the four extra key inputs are the annoying part).I find that much faster than manually typing
find "$HOME" -name "random executable with spaces.exe" -type x -exec wine "{}" \;, or opening an editor to insert backslashes.Why on earth not just type
wine ~/randomand then hit tab to autocomplete? Or you could dowine `echo random*`AFAIK, if $file is a filename with spaces, then
some_util ${file}will not split the filename.If the path to the dir is longer than
$HOME, say,$HOME/Tools/modding/hd2-audio-modder/wwise/v123456789_idr_but_its_a_long_one/random file name with spaces, it makes more sense.I’ll try using the braces syntax, if it does prevent word splitting I wasn’t aware of it, though it’s still slightly inconvenient (3 key inputs for each brace on my kb) and I’d probably still use quotes instead if I had to use Bash and had the file path in a variable for some reason.
… though at this point I’m probably overthinking it, atm I don’t recall better examples of my distaste for Bash expansion shenanigans.
Did some testing, here’s what I found.
Beware, it devolves into a rant against Bash and has little to do with the original topic - I just needed to scream into the void a little.# Zsh function argn { echo $#; } var='spaced string' argn $var # Prints 1: makes sense, no word splitting here var=(array 'of strings') argn $var # Prints 2: makes sense, I'm using a 2-wide array where I would # want 2 arguments (the second one happens to have # a whitespace in it)# Bash function argn { echo $#; } var='spaced string' argn $var # Prints 2: non-array variable gets split in 2 with this simple reference; # I hate it, but hey, it is what it is argn ${var} # Prints 2: no, braces do not prevent word splitting as I think you suggested var=(array 'of strings') argn $var # Prints 1: ... what? echo $var # Prints array: ... what?!? # It implicitly takes the first element? # At least it doesn't word-split said first element, right? var=('array of' strings) argn $var # Prints 2:
Upon further investigation:
# Bash mkdir /tmp/bashtest ; cd /tmp/bashtest touch 'file 1' touch 'file 2' stat file* # Prints the expected output of 'stat' called on both files; # no quotes or anything, globbing just expands into # 2 arguments without *word* splitting files=('file 1' 'file 2') stat $files # stat: cannot statx 'file' # stat: cannot statx '1' # WHY? WHY DOES GLOBBING ACT SENSIBLY WHEN ARRAYS DO NOT?I get that the Bash equivalent to Zsh’s
$arrayis${array[@]}, but making$arraybehave like it does in Bash has no advantage whatsoever.
… IS WHAT I WOULD SAY IF THAT WERE TRUE! YOU ALSO HAVE TO QUOTE"${array[@]}"BECAUSE WE LOVE QUOTES HERE AT BASH HQ!# ... continued from before stat "prefix ${files[@]}" # stat: cannot statx 'prefix file 1' # (regular 'stat' output for 'file 2')While this behavior doesn’t make much sense to me, it also doesn’t make sense for me to write that “prefix” within the quotes in the first place, right?
YES. BECAUSE SPLITTING IS NOT WHAT YOU EXPECT WHEN YOU PUT STUFF IN QUOTES.Sorry, I’ll stop.
My bad, I was thinking of zsh. And I think it’s configurable there too so may not behave that way according to your settings. But it is at least the default on Mac.
I use Zsh too, though at this point is becoming detrimental to my (already limited) Bash skills because of features like the
${^array}{1,2,3}syntax which I use in some scripts of mine, which in turn I wouldn’t dare try to translate to Bash.
at least you/arent/using\ linux
smells like skill issue tbh
tools which cant handle being installed/run on directories with spaces are so annoying
tools which cant handle being installed/run on directories with spaces are unacceptably common
You are clearly not a command line user :)
I vaguely remember
zshin Manjaro (by default) having a tab completion that automatically added the slashes.
Never set it up myself though.But I really hate having to worry about quoting my file variables in scripts.
So much, that after a certain complexity, I just give up the script and make the thing in C++.
Oh, and if I make a script that doesn’t handle file names properly (because it’s not required in that specific use case), I make sure to delete it after use, to prevent mistaken use later, which would otherwise cause more headache than just having to rewrite a script.
You can just start the path with a quote and it will auto complete with spaces. I spend a lot of time correcting files with spaces replaced now. The spaces are better. I think music is the most annoying, since I like to use tools like EasyTag to extract metadata from filenames.
So please stop.naming_files.like_this.its_stupid
You can just start the path with a quote and it will auto complete with spaces.
Oh, you’re right. I just tried it out and it worked the same way.
I wonder what gave me the misconception the it doesn’t by default.
Mv /home/“$USER”/Downloads /home/“$USER”/downloads










