_cnt0

Oh man, I am too tired. I read that as "Some comrades can't be executed by keyboard shortcuts ..." and was like, wtf! Then I read it again.

It's certainly no bad habit to handle spaces in scripts preemptively, and obviously they do occur in the wild. Quotes from ls output do not get piped to other commands. I had to look that up myself right now, because it has been quite a while since it mattered to me.

$ touch 'file with spaces in name'
$ ls
'file with spaces in name'
$ ls | cat
file with spaces in name
$ 

Looking through some scripts I wrote back in the day, I seem to like to use ls -1 in scripts. I guess that reduces ambiguity on what the separator is.

Feel free to travel back in time and have a discussion with Ken Thompson in ~1970, whether spaces in file/folder names should be allowed in the first place. I for one use an underscore instead, whenever I have control.

It's really neither a bug nor a problem. It is very reasonable default behavior to enable piping to or parsing by other commands because space is the default separator for arguments.

I'd wager a guess, that all file/folder paths that are surrounded by quotes contain at least one space!? And you're talking about the output of ls? It's rather unlikely, that installing any software has changed that behavior. It's just a display feature, to denote that "two" parts separated by a space are actually one.

now

They have had it for a while ;-)

ps: I hope I got the tense right. Not a native speaker and slightly drunk. They still have it.

one of those vendors

Which one?

I have a Slimbook PRO X AMD. Except for the rubber bands on the bottom coming loose after ~2 years, it just works. And I never had a laptop from any manufacturer where the rubber feet/bands did not start to peel of after a few years.

Up until now, I've only been commenting on other peoples comments to nitpick. I think it is time to give you a comprehensive answer on my own:

You didn't mention, what distribution you are using. Either way, you should use your distributions package manager to install zsh. Wherever that places the zsh binary is fine; you should not change that! If you want to know where the zsh binary is located, you can issue the command which zsh. That zsh should somehow be dangerous as a root shell because it is not POSIX compliant is nonsense. You can use whatever you like as a shell for root. If you don't want to change the login shell for root, you can just start every shell from any shell by executing it's binary (i.e. in bash type zsh, or the other way around). If you want to know what shells on your system are considered viable login shells by your system, you can issue the command cat /etc/shells; in your case it should list /usr/bin/zsh. If you want to change the login shell for a user, as that user run chsh -s ... where ... is the fully qualified path of a valid login shell; to be sure to not make typos or use an alternate path, you can combine that with which, and for example to use zsh use the command chsh -s $(which zsh). If you are the sole user of your system, I'd strongly recommend using seperate configurations for zsh for your normal user and root.

So now when I drop into a root shell I don’t get [...]

Issuing su - or sudo -i or logging in as root in a full screen TTY (ctrl+alt+F*) will spawn a new shell (the login shell configured for root). If you are unsure, what shell you're currently in, you can find that out, by issuing the command readlink /proc/$$/exe. If readlink is not available on your system, you can use ps -fp $$; be aware though, that that will show you the command the shell was started with, not necessarily the path of the shell executable.

If you want to write scripts you should always specify the shell it should be executed by with a shebang. For maximum portability/compatibility (do you like to distro hop? want to share it with a friend/the internet?) you should use env in the shebang. For you, if you want to script with zsh, that simply means always having #!/usr/bin/env zsh as the first line of scripts.

While this is true for most linux distributions, it's not true for all and there are other POSIX compliant OSs which are not linux at all:

/ # grep -i pretty /etc/*-release
/etc/os-release:PRETTY_NAME="Alpine Linux v3.18"
/ # ls -ld /bin
drwxr-xr-x    2 root     root           862 Aug  7 13:09 /bin
/ # 

As you can see, /bin is not a symlink there.

Nothing beats Kile for LaTeX, imho.