Take my upvote.
PseudoSpock
I'm picturing Daffy Duck and Bugs Bunny swapping hunting signs on a tree... "Linux season!" "GNU season!", back and forth. The rest of us just watching like Elmer Fud.
Don't know about everyone else, but here are some of mine:
- Stick to posix compliance shell code, wherever possible
- Please wrap your variables with { }. Just please.
- Global variables being exported in all caps
- Local variables in lower case
- $() instead of ` `
- Comment anything complicated, comment what section, comment usage
- Include usage output if options are not recognized
- Use case instead of if / elif, where possible
- 80 characters or less per line, where possible
- HERE docs in designated section, marked by comment blocks
- Comment your functions immediately above it's definition
- Add comment "#End of function Xyz" at line immediately below a function, with replacing Xyz with name of that function
- 2 space indentation
- Multi-line strings: First line open with quote and first line of string, followed by a backslash , subsequent lines properly indented and backslashed. Last line, properly indented and close quoted.
- Break up multiple piping of commands with |\ and a new line where it makes sense to look nice, assisting readability
- Echo what the script is doing once in a while if the user will be waiting for a while
- Please don't do shar archives, or byte located binary extractions, make a script and a separate tarball - Helps a ton if we have to change it, like say... swapping out a bundled java runtime built for x86_64 with one for aarch64
- If the script will run for a very long time, check for tmux or screen and also the TMOUT variable... Give a warning to the user their connection might time out before the script is done if they don't unset TMOUT, and try using tmux or screen to allow the script to continue in the background, even if you do get disconnected
- Make use of logger
- I try to organize a script this way: 1. Shebang, 2. Initial variable definitions, 3. Functions, 4. runtime execution code, which might be best outside of a function, and calling functions. 5. Clean-up (remove pid and lock files, tmp files, etc etc.)
Why on Earth would you use that thing?
Books, periodicals, internet searches, practicing everything at home on a personal equipment until you've got it all mastered. If one can't learn that way, take courses. The way the rest of us did it. Once you've got that, you have the ability to learn anything new coming... and can hit internet forums with well formed questions, complete with context. Staying on nano/pico, there is just no excuse if you've already been heavily using linux for 3 years or more. It's an editor for those who are still in the beginning of the SELF learning phase. It should never be included in any distro's default install except for school classroom centered distros. Just because something is easy to use doesn't mean it's installed as a standard everywhere. Folks learning this as their craft need to learn how to sit in front of any Linux or Unix and use standard tools to achieve what they need to do. That means learn your Vi. Learn your Posix shells like Ksh, Bash, Zsh, Dash, not the nano of shells, fish! Learn your Python, your Perl. Learn your SysV 'isms in addition to your SystemD. Learn your csh (tcsh will do). Learn your terminal control codes. Learn your SysRq funtions. Learn your tmux, your gnu screen. Learn with and keep handy your books for awk, sed, patterns, perl. Learn your mkfs', the different filesystems and their benefits, their options and tools, how to resize. Learn your MD raid. Learn your LVM. Learn various encrypt at rest options. Learn containers. Study and remember the differences between gnu, bsd, and sysv tools like tar, cpio, find, and even ps. Books books books! Practice practice practice! Study study study!
And when you got that done, look up and see what you've missed while you were doing all that, and start in on all that new stuff. Wash, Rinse, Repeat. Never stop reading, studying, practicing, learning.
That's how. Oh, and delete nano!!!!
Well yeah, for computers in kindergarten schools.
There are 15 lights!
There should be no such thing as non-advanced users.
That explains a lot of what I've been experiencing for quite some time now. Laptop's internal keyboard types fine in grub, but usb keyboards the password is wrong more often than not.
From the system's DMI. You can check it yourself with
dmidecode
. Those values are largely unchangeable, and those that are, will probably require a tool from the vendor to change, which are usually for internal use only within their company.