I have a public git repository that I keep those kinds of recipes in.
So on a temporary system, I usually clone that repository first, so I can reuse past solutions.
this post was submitted on 01 Jan 2025
7 points (100.0% liked)
Shell Scripting
1378 readers
1 users here now
From Ash, Bash and Csh to Xonsh, Ysh and Zsh; all shell languages are welcome here!
Rules:
- Follow Lemmy rules!
- Posts must relate to shell scripting. (See bottom of sidebar for more information.)
- Only make helpful replies to questions. This is not the place for low effort joke answers.
- No discussion about piracy or hacking.
- If you find a solution to your problem by other means, please take your time to write down the steps you used to solve your problem in the original post. You can potentially help others having the same problem!
- These rules will change as the community grows.
Keep posts about shell scripting! Here are some guidelines to help:
- Allowed: Release Announcement of a command-line program designed for scripted use (e.g. bash, bats, awk, jq, coreutils/moreutils)
- Allowed: Tutorials on using shell languages or supplementary tools designed for scripted use
- Allowed: Code review/help requests for shell languages or supplementary tools designed for scripted use
- NOT Allowed: Announcement of a CLI or TUI program that is not designed for scripted use (Yes, your fancy Zsh plugin which pretty-prints the date and time using only builtins is very cool, but unless you actually want to discuss the code itself, please check out !commandline instead!)
- NOT Allowed: Domain-specific tutorials that do not involve shell scripting as a core component (e.g. docker-compose, ansible, nix). If you really love one of these, I'm sure there's a community out there ready to talk about them!
- NOT Allowed: Code review requests for non-shell programming languages and configuration languages (e.g. Python, Yaml)
In general, if your submission text is primarily shell code, then it is welcome here!
founded 2 years ago
MODERATORS
Me, too, and it works for other Linux distros, but in this case it's a Windows Sandbox. Unless it's copy and paste, for this case it wouldn't be worth it and I assume there can be similar situations in the future for other reasons.
I once started to work on auto-setup scripts for Windows, but the unpredictable nature of it made me give up on that :D
I once started to work on auto-setup scripts for Windows, but the unpredictable nature of it made me give up on that :D
Yeah. This still sucks, but is getting substantially better every year. My lazy rule of thumb is if I find a solution inside of WMI (Windows Management Interface), then I'll script it. Otherwise, I figure I'm wasting my time as it will change anyway.
but in this case it's a Windows Sandbox.
If it's Windows 10 or later, winget is preinstalled (sort of / mostly) and has acess to a release of git. (WinGet is available on 'Modern' Windows 10 and later., and it may take a few minutes to bootstrap itself after first login.)
So I'm able to bootstrap this pattern on Windows with something like:
winget install --id Git.Git -e --source winget
I'm pretty sure I just use winget install Git.Git, but someone on SO recommends the above longer version. I'm guessing it prevents an interactive prompt, since there are more than one package source for git, if I recall.
I assume there can be similar situations in the future for other reasons.
You may be happily surprised - we don't agree on much in technology, but bootstrapping with git is supported in places where nothing else works, and is finally also even popular among Windows engineers.
I recall encountering two exceptional cases:
- An 'almost never change anything' immutable distribution like
Batocera. - A host with no Internet access.
In both cases, I still version the relevant scripts in the same git repository, but I end up getting scrappy for deploying them.
On an immutable distribution, I'll curl, wget, or Invoke-WebRequest to get a copy of each file I need, as I need them. I encounter this often enough that I find it worth putting copies into a public S3 bucket with a touch of nice DNS in front. It does wonders for me remembering the correct path to each file.
On a completely offline distribution, I run git init --bare in a folder on a the root of a thumb drive or network share, and then I git push a shallow copy of my scripts repo to it, and git clone from it on the machine to work on. I also simply file copy a copy as well, in case I cannot get git bootstrapped on the offline machine.
I do still bother with the git version because I invariably need to make a tiny nuanced script correction, and it's so much easier (for my work patterns) to sync it back later with git.
I think it really depends how much time you actuall spend working on these temporary systems, and what mechanisms are available for automatically configuring those systems, even temporarily. You can generally assume that some version of bash is available on all systems, so if you have a bashrc that you like, you could use sshrc or kyrat to at least bring over some functions and aliases (I used sshrc long ago but haven't tried kyrat): https://github.com/cdown/sshrc, https://github.com/fsquillace/kyrat
If you do want to use nushell on remote systems, possibly xxh would enable that; I haven't used it personally, but it looks promising: https://github.com/xxh/xxh
If you're not using ssh, then it really depends what you are doing.
This is cool! It doesn't fit my current situation. The temporary system I'm dealing with now is a Windows Sandbox for a school project. While it could take a few minutes to install winget and the necessary tools, I'd rather not risk the potential of troubleshooting time, because of the limited amount of time I work on it physically (and because I'm cursed with troubleshooting nightmares on Windows).
But I'll have a look on xxh. It could definitely improve my comfort with servers that do not maintain nushell packages.
Hm, I'm not sure what you're looking for, then.
How are fish abbreviations different from nushell aliases for working on temporary machines? Surely your Windows sandboxes don't have fish installed?
Since fish abbreviations get replaced by the actual abstracted content before the execution, I'm more concise about the tools. And thus I'd remember the ways without my setup better. Then again, it only works for small stuff.
Oh, I see, so you don't exercise your muscle memory but you at least see the "raw" commands more often.
Looks like this was suggested in nushell, and someone came up with a way to emulate the behavior manually: https://github.com/nushell/nushell/issues/5552#issuecomment-2113935091
Edit: there's another issue for this: https://github.com/nushell/nushell/issues/5597
Hopefully nu will decide to implement it properly in the future.
What's the nature of the temporary system?
I would consider; remote/temporary systems are not necessarily mine, or setup is not worth it given my concerns on it; There's different options to install or configure existing shells, I could take my config with me; if it's a temporary system maybe it's based on a template that could be adjusted, or auto-setup scripts could be adjusted
It would depend on how much I use it, how much I miss my setup, or how irritated I get because of missing stuff, and considerations of whether it's worth it (to me).
I'm someone who adjusts their environment to their needs and wants, moreso than other colleagues I see. Many people seem to simply accept existing environments and (to me) annoyances.
When I remote into servers, it's not typically where I would use much Nushell functionality. Bash and vim is good enough for those things, with just a little bit of configuration. I don't plan on installing it on work servers, but have recently thought I may install it on my own server for convenience.