Obligatory XKCD
Hmmm command not found, let me just try the same command a couple more times, this time it will work right?
In IT teaching users to actually read and understand errors is always an uphill battle.
I learned early in my software engineering career these two beautiful rules of debugging:
- Read all of the words
- Believe them
… but
cd
is a built-inIt would be pretty useless if cd was a child process that changed its own directory, only to return to bash and be back where you started.
-1 accuracy point ( ◞ ﹏ ◟)
linux 4.5-rc5 had efivarfs fixed to prevent “rm -rf /” bricking uefi motherboards – so maybe someone can try it out? :]
Having been in this situation (the only binary I could use was
bash
, althoughcd
was a bash builtin for me),echo *
is your friend. Even better is something like this:get_path_type() { local item item="$1" [[ -z "$item" ]] && { echo 'wrong arg count passed to get_path_type'; return 1; } if [[ -d "$item" ]]; then echo 'dir' elif [[ -f "$item" ]]; then echo 'file' elif [[ -h "$item" ]]; then echo 'link' # not accurate, but symlink is too long else echo '????' fi } print_path_listing() { local path path_type path="$1" [[ -z "$path" ]] && { echo 'wrong arg count passed to print_path_listing'; return 1; } path_type="$(get_path_type "$path")" printf '%s\t%s\n' "$path_type" "$path" } ls() { local path paths item symlink_regex paths=("$@") if ((${#paths[@]} == 0)); then paths=("$(pwd)") fi shopt -s dotglob for path in "${paths[@]}"; do if [[ -d "$path" ]]; then printf '%s\n' "$path" for item in "$path"/*; do print_path_listing "$item" done elif [[ -e "$path" ]]; then print_path_listing "$path" printf '\n' fi done }
This is recreated from memory and will likely have several nasty bugs. I also wrote it and quickly tested it entirely on my phone which was a bit painful. It should be pure bash, so it’ll work in this type of situation.
EDIT: I’m bored and sleep deprived and wanted to do something, hence this nonsense. I’ve taken the joke entirely too seriously.
was a bit painful
Well that’s an understatement
My pain tolerance for shitty input methods has been permanently warped after experiencing psychic damage from using Teamviewer to connect to a system over a very flaky HughesNet satellite link. I was working for a vendor that supplied a hardware networking box to a stupid retail company that sells food and shit. I just wanted to ssh to our boxen on a specific network so I could troubleshoot something, but the only way I could get to it was via putty installed on an ancient Windows XP desktop on the same network as our box that could only be accessed with Teamviewer. My favorite part of that was that the locale or something was fucked up, so my qwerty keyboard inputs were, like, fucking transformed into azerty somehow?? The Windows desktop was locked down and monitored to a tremendous degree, so I couldn’t change anything. The resolution was terrible, the latency was over a second, and half of my keyboard inputs turned into gibberish on the other side.
Oh, and I was onsite at that same company’s HQ doing a sales engineering call while I was trying to figure out what was wrong. I spent 5 days sitting in spare offices with shitty chairs, away from my family, living that fucking nightmare before I finally figured out what was wrong. God damn, what a fucking mess that was. For anyone reading this, NEVER WORK FOR GROCERY/DRUG STORE IT. They are worse than fucking banks in some ways. Fuck.
EDIT: also, I asked ‘why Teamviewer’ and the answer was always shrugs. This was before the big TeamViewer security incidents, so maybe they thought it was more secure? Like, at least they didn’t expose RDP on the internet…
This isn’t programming, just someone who sucks at bash.
How else are you going to open your files in nano to do the programming on the prod server?
what’s a nano?
The beginner (and better) version of vim?