After a while trying to understand if either ksh or zsh provided a way to prevent taking strings and undefined variables as 0 when doing arithmetic evaluation, there seems to be no feature specifically for it, sadly.
Closest is using set -o nounset (ksh) and setopt no_unset (zsh) to prevent undefined variables from evaluating to zero. If a "string" contains only numbers, a dot and whitespace, it will be treated as a number. Also, if it only contains the name of any other variable and whitespace, it evaluates to that.
Not that I expected shell languages to provide accurate arithmetic.
As a bonus though, it was cool learning about ksh's compound variables, force_float option and especially discipline functions.
A one-liner for exporting your Conda environments for re-creation on another machine… but you might want to have a look at whether you actually need to recreate those environments.
for envs in $(conda env list | egrep -v "^#" | awk '{print $1}'); do echo "Exporting environment: $envs"; conda activate $envs; conda env export --no-builds | egrep -v "^prefix" > "$envs.yaml"; conda deactivate $envs; done; ls -l *.yaml
Also a bit lost regarding some path issues on #HaikuOS . To use my usual scripts, I installed zsh + ohmyzsh andI symlinked
~/config/settings/.zshrc
to ~/.zshrc
Everything seems to work but python stuff only works properly in bash.
In zsh pip says:
/bin/python3.10: can't open file '/boot/home/pip'
(the last thing being any path I am currently in). PATH is the same so it must be some Python env variable ?
Well.. this fixes it for pip …but not for packages installed by it (for example compiledb).
They are installed in :
/packages/python3.10-3.10.13-3/.self/non-packaged/bin
So I add can this path (which will inevitably change) to my .zshrc but why the hell doest it works with bash without anything in PATH or any other env variable ?
So I'm using #powerlevel10k on top of #ohmyzsh on top of #zsh (with plugins) on top of #iTerm2. At this point I have no idea which terminal features come from which software. And if I really need all of these installed
As I juggle both a Linux and FreeBSD server - is there a real good reason to pick one shell vs others? They naively seem similarly capable, and it's more a matter of just picking one with good tutorials and running with it? I'm hardly a shell-scripting wizzard. #freebsd#linux
I've wasted literal years dabbling in beautiful looking shells (#fish / #zsh), or trying to enhance my #bash with needlessly bloated decoration frameworks (oh-my-bash/starship), I've decided to roll my own bash prompt in 20 lines.
It shows everything I need: user and host only over ssh, active environments (#conda, venv, or #guix), and the #git branch if I'm in a project.
That's it. Runs quick and easy.
Just add the code (see the alt/hover text in the code image) to your #bashrc, and voila!
TIL that for some reason unlike on Linux, FreeBSD, and even Haiku a #ssh session on Mac doesn’t setup the path automatically when you execute a command on start.
So if you want to launch tmux on Mac from ssh you must source your profile first like this (otherwise it won’t find tmux in the homebrew path):
ssh user@192.168.0.33 'source ~/.zshrc; tmux new-session -A -s "SessionName" '
It has been long on my todo list but finally I've tried out the #eat terminal emulator for #emacs and it's brilliant! I didn't try it earlier because the homepage only mentions shell integration with #bash and #zsh but it works nicely with #fish, too. One thing I can't get working is directory tracking. I think I configured my #starship prompt that it emits OSC 7 shell escapes (but how would I know for sure? They're invisible!). Doesn't eat recognize them, @akib?
Terminal ist nicht gleich Terminal. Wie bei vielem hat die Anwenderin eine grosse Auswahl. Im Titelbild seht ihr einen Funktionsvergleich der häufigsten Linux Shells.
Question for any #zsh people, especially ones using the fast-syntax-highlighting plugin:
I recently figured out that plugin also colorizes a bunch of commands, among them is #git. Now, I've wrapped git in a thin script called g, which without arguments starts #tig, or if given any arguments just passes them on to git.
I want to get fast-syntax-highlighting to work with my g command as well. It literally needs to treat it just the way it does git. I tried the stupidest thing i could thing of, which was to copy -git.chroma into -g.chroma (why with the dash... my goodness...) and just change the relevant occurrences of git with g, renaming functions and variables too so they don't somehow end up clashing with the ones for git. It achieved nothing.
Anyone ever actually added custom highlighting to fast-syntax-highlight in a similar way?
There's an open (unanswered) issues about aliases, but this doesn't fit into that case exactly since here g is a separate script, not just a shell alias for git.
Whenever I need to create a quick #cli script (and I can't easily do it in #bash or #zsh) without tests and for ease, I'll typically use #python. I've spotted others doing the same in #nodejs, #php, etc. Does everyone go back to the language they're most familiar with in these scenarios?
@BrownianMotion@nixCraft Because you might be on #macOS or another distro with an older version but want to use a newer one yourself. On the #Mac you could install the newer one with @homebrew, add its path to /etc/shells, then set your account’s default shell to it. Or do the same with #zsh which has been the default for the past few major releases.