Sure, it's annoying and pedantic to nitpick someone's helpful answers and snippets. But sometimes the goal is to foster a better understanding, and reduce superstition and cargo-culting.
"sync<CR>sync<CR>sync<CR>reboot<CR>" became an idiom for various reasons. Then it became "sync; sync; sync; reboot" and deemed equivalent, which was missing the point that physically pressing "enter" introduced some human-length pauses into the process. Then "reboot(8)" incorporated those syncs, and "shutdown(8)" provided more flexibility, but the idiom persisted.
And to this day, the tier-1 support script says to clear your cookies and cache, try a different browser, factory reset your phone, disable firewall, disable AV, reboot your router, bypass your switch and plug in one device directly, wait 15 minutes and try again, and we've abandoned all attempts to understand, diagnose, or find root causes when the underlying systems are too diverse and complex to understand or keep your tech's expertise up-to-date.
Strawman--nobody said that. All I suggest is that if you wish to accomplish a particular task, then read the manual at that point, and find relevant ways to invoke the command.
The options I've memorized over the years are the ones I've used the most often, and this inertia can lead to ignorance, unless I periodically revisit the manual page to see what else can be done.
Every IT/CS instructor will tell you that your source of truth is the vendor's documentation. Don't waste your time Googling Stackexchange when the manual pages are available right on the system, on a website, or however. The manual pages are written by the developers and tech writers to specifically tell you how to use these commands.
You can either "cat for clarity" for the rest of your career, or you can learn new methods like shell redirects, "tee(1)", "exec <file; while read var; do cmd; done". I wouldn't be surprised if people start their careers thinking that "cat" is just for starting up a pipeline. Other students may be taught that "cat" is an elementary way to just put file contents on their terminal screen, and then they'll subsequently learn how "more(1)" is superior in this regard.
"When all you have is a hammer, everything looks like a nail."
I am not sure how passwords are relevant to the pointless chaining of two distinct commands, rather than invoking a straightforward "sudo -s".
People writing "sudo su" are simply imitating a common StackExchange idiom without knowing why.
"su" requires passwords unless invoked by root. "sudo" may be configured to permit/deny specific commands. So if you write that, then you're saying 'become root via the sudoers(5) config and then fork, exec, become root again via the setuid binary "su", in order to run an interactive shell.'
It's a poor habit to be promoting, because it assumes things about the configuration and suggests that "su" is equal to other particular "sudo" maintenance commands, when the point is simply to drop into a root shell, which is a facility provided directly by "sudo", if you'd only read the manual page and learn its options.
Nothing will stop you from invoking "sudo -s" without a password, without another fork/exec, without another suid utility carrying a significantly different authentication model.
Doesn't "sudo -s" keep the current user's environment variables as opposed to "sudo su"?
I admit that in the context of doing "ls /sys/module" it's likely not a huge problem, but I do (in my gut) feel that for running an elevated command, it's cleaner to just drop in as actual root, instead of masquerading as root.
> Depending on the security policy, the user's PATH environment variable may be modified, replaced, or passed unchanged to the program that sudo executes.
Essentially a "maybe, depending on what your OS policy is", proving that your comments are less than helpful.
https://news.ycombinator.com/item?id=23341711
Today it's giving way to "useless use of su" where admins aren't aware of sudo(8) options like "-s" or "-i"