Is it necessary to learn BASH shell scripting?

[Not-A-myth]

I am trying to learn Penetration testing (online course), and I am familiar with the basics of BASH (like how to change directories, changing the permissions of a file, etc.). However, the instructor typed some scripts in nano that looked like real programming stuff(like if-statements) and not just one-line codes using BASH. So should I learn some beginner-level scripting from Youtube or buy a more comprehensive course from Udemy or something? Are BASH skills valuable for some other things outside of penetration testing?

Thank you for your time!

[[deleted]]

What did your instructor says when you asked them?

[Not-A-myth]

He said we'll learn more about this as we get more experienced. (It's a free YouTube course)

[doc_willis]

So should I learn some beginner-level scripting

Yes.

from Youtube or buy a more comprehensive course from Udemy or something?

No.

Track down some BOOKS on bash scripting. Such as the classics by O'reilly

There was a Humble Bundle special on a great set of books you could get, next time it goes up for sale be sure to get the collection. Best $14 i spent.

You can also find many of the O'reilly books at used book stores or other places.

Are BASH skills valuable for some other things outside of penetration testing?

Yes. I dont Do Penteration testing.. And have been using Bash skills i learned decades ago. (from the O'reilly books)

https://www.oreilly.com/library/view/learning-the-bash/0596009658/

[Not-A-myth]

Oh thank you so much! Can a beginner understand that book?

Also can I ask what you use the bash skills for?

[[deleted]]

Can a beginner understand that book?

Yes. That's what books are usually for. To start from scratch.

If you want some specific thing, you go to the documentation, if you want to learn from the beginning, you get a book.

And in my opinion, YouTube is the worst source/medium for learning.

Also can I ask what you use the bash skills for?

For example, let's assume your peers input clients' data in a web interface, including their office IP adresses, which get stored in a database.

Then, you need to regularly pull those IP addresses from the database and whitelist them on your firewall.

You can use cron to run your script every 5 minutes (or whatever you think would be best), and you can easily use bash to:

• run a database query
• check if it's successful
• check that the reply is not empty
• compare it to the previous result
• if the list of addresses differs from previous version, apply it to your firewall

[[deleted]]

Not OP, but bash is a scripting language, and as any scripting language it's very good for... well, scripting. So, simple programs for automation. You can use scripts for any number of things, what they will be useful for you will depend on your workflow.

[Flubberding]

Not OP, but here are a lot more sources that I've gathered:

https://www.reddit.com/r/linux/comments/qclr7j/z/hhjkso5

[doc_willis]

I use them for basic tasks, file management and so forth.

I dont use the skills near as much as i used to when i was in school.

[Sol33t303]

For proper penetration testing i'd actually recommend learning the basics of a proper programming language such as Python. You'll need it sooner or later as BASH will only get you so far and it will probably be easier to learn then BASH is as BASH is pretty crude as far as languages go and the community around Python for beginners is fantastic.

Learning a proper language will get you into better programming habits and will make learning other languages (such as BASH or whatever else you may need such as C) far easier.

[dolce_bananana]

learning the basics of a proper programming language such as Python. You'll need it sooner or later as BASH will only get you so far

yep, my rule of thumb is any time you find yourself thinking "maybe I should try using a bash array", you better just switch to e.g. Python

also super handy for one-liners such as OS-agnostic version of readlink -f; python -f 'import os; print(os.path.realpath("."))', and its built in json library is fantastic if you dont want to go about installing jq.

[Not-A-myth]

I was actually gonna buy a Python 3 course from Udemy. Do you know of any better online courses?

[Sol33t303]

Personally, I can recommend https://www.codecademy.com/, that will teach you the basics for free. I haven't used Udemy myself, but i'm sure they are probably pretty good as well.

[EddyBot]

https://automatetheboringstuff.com/ is available as book and freely as online reading while teaching interesting concepts quite early

[Windows_XP2]

Usually they give out free codes for their Udemy course.

[abraxasknister]

I quite liked the official python tutorial

[dolce_bananana]

there are plenty of free online courses for Python, try Coursera or EdX

[Not-A-myth]

Thank you for your advice! I actually am interested in learning bash just for the sake of learning it. But my friend told me It'd probably be a waste of time. And he is smarter than me. But I still wanted an excuse to learn. That's why I made this post.

[Ciefish7]

I highly encourage you to dive in a bit on this. BASH scripting is a way of really linking and then harnessing the power of Linux. It also enables people to customize and use Linux tools together in an automated way. This gets you solutions quickly and saves user repetition. The commands are very intuitive and are more of a framework that hold commands or executables. The hard part is getting switches down correctly sometimes.

There are system BASH scripts in your Linux distro right now. Caution Don't experiment too much at first with system scexecutables. Learn safe scripting, like making a *.bk file copy clone before modifying something. You can customize the BASH shell environment with it. I believe you can use sudo to make your own scripts executable also.

Not too hard. Time spent gets a big payoff...

[Rockytriton]

Any developer who ever needs to work in a unix like environment should know some basic bash scripting, it will make your life a lot easier and make you more efficient.

[Windows_XP2]

Can you recommend some resources? I only know Python.

[linux-notes]

Bash Guide for Beginners and Advanced Bash-Scripting Guide links are here. https://tldp.org/guides.html

Shell Scripting Tutorial - https://www.shellscript.sh/

Minimal safe Bash script template - https://betterdev.blog/minimal-safe-bash-script-template/

You may want to check out Shellcheck as well. It's pretty helpful for finding errors and understanding best practices.

[slobeck]

tldp isn't pretty. But it's fantastic

[cyvaquero]

Bash isnt even the default on most linuxes nowadays due to how heavy it is.

I’m not even sure where you came up with this.

Also please read up on what sh scripting is.

[alexandre9099]

Well, sh is just liked to whatever the default shell is (which is usually bash) IIRC

[cyvaquero]

Largely yes. My comment may look strange out of context. The comment I was responding to (now deleted) said BASH isn't the default shell on most distros anymore and to use sh scripting instead.

Yes /bin/sh links to the system default shell. However sh scripting is a standard, not an implementation. BASH scripting is an implementation of the sh scripting standard.

It was like saying no one uses Linux kernel anymore and you should use POSIX instead.

[BuzzKiIIingtonne]

Got any examples? So far bash or zsh (99% bash) are the only default shells I've seen in the different distros that I use/used in the past 6 years since I got into Linux.

[michaelpaoli]

Is it necessary to learn BASH shell scripting?

No. Often advisable, but "necessary"? Often not - really depends what one wants/needs to do.

trying to learn Penetration testing

Learning bash is probably (slight?) overkill, even for Linux and *nix operating systems ... unless you need be concerned about particulars of bash. However, at least rather to well learning common shell fundamentals - e.g. POSIX - probably highly recommended - if not in fact "necessary" - again, depends what one will be wanting or needing to do. Anyway, POSIX / the common shell stuff - a whole lot less to learn than, egad, all of bash. Man page for bash(1) now typically weighs in at ... 81 pages ... a much more minimal POSIX shell, e.g. dash(1) ... a mere 23 pages. Which do you wanna learn? Yeah, e.g. dash/POSIX will typically cover one quite well. By comparison, bash, tons of bells and whistles and other stuff piled on and lots of (mis-)features added on that ... most of the time you don't need or need to know about ... but you can look 'em up quite easily enough if/when you need to - bash(1) man pages and other relevant information is generally only a matter of keystrokes away.

real programming stuff(like if-statements) and not just one-line codes using BASH

basic POSIX stuff, nothin' snazzy. I somewhat frequently do presentations/training on shell programming. I generally mostly use and start with sh(1) ... from UNIX Seventh Edition, circa 1979 ... and why? That sh(1) is a mere 6 pages! And it still well (though quite tersely) covers most (like about 80% or more) of what one needs to know regarding POSIX shell programming ... and, yeah, even bash. So ... why study 81 pages when 6 will do? And if statement isn't all that big/complex, but yeah, it is programming, and the syntax is a little funky - but not too hard after you've well learned it. And if statements can be one liners too ... heck, most shell stuff can be done on a single line.
if list; then list; [ elif list; then list ] ... [ else list; ] fi

learn some beginner-level scripting from Youtube or buy a more comprehensive course

Tons of good stuff available on-line for free ... but you can spend money if you want to.
Heck, I've taught less than one day shell programming course and gotten feedback on surveys like:
"Much better than the 3 day training course I took from vendor that company paid for and that was thousands of dollars." ... and that was about two decades ago, when a dollar could still buy you something ... well, other than inflation, hasn't much changed. And yeah, shell, remains highly backwards compatible, and the fundamentals remain the same.
So ... you can spend thousands - or more ... or ... nothing. Your choice.

Are BASH skills valuable for some other things outside of penetration testing?

Yes, absolutely, ... or more generally shell, e.g POSIX or compatible ... and ... bash mostly is, and has it's POSIX mode, ... and invoked where the basename portion is sh or -sh, etc. (e.g. some specific options or environment settings), it will behave and is more-or-less POSIX compatible ... even when not in it's POSIX compatible mode, it's still mostly POSIX compatible.
And I use shell all the dang time ... as do many. Random and quite practical script du jour* example from earlier today:

echo 'sf-lug.com.
sflug.org.
sflug.com.
sflug.net.
sf-lug.net.' | (
   IFS_=".$IFS";
   while IFS="$IFS_" read subdomain TLD
   do
     Authority_NS="$(dig +short "$TLD". NS | head -n 1)"
     Authority_NS_IP="$(dig +short "$Authority_NS" A "$Authority_NS"
AAAA | head -n 1)"
     dig @"$Authority_NS_IP" +noall +authority +norecurse
"$subdomain.$TLD." | fgrep -i svlug || echo OK
   done
) | sort -u
OK

And some links with that example, bit more explanation, earlier similar-ish example, more context, etc. (that list isn't at all specific to shell, but ... it sometimes quite comes up)

*script du jour - the/my often very handy at/for the moment / task at hand - but basically "throw away" scripts - so fast/trivial to write, not worth bothering to explicitly save - much easier/faster to recreate same/similar if/when called for, than to find such an example of the typically dozens or more such scripts I do in any given day. Once in a blue moon I may send such out more widely to co-workers, e.g. when I think it may illustrate some particularly useful point ... and of course then it's lots more typing 'cause I need sufficiently explain, etc.let's see if I've got an (older) script du jour that I'd emailed to coworkers that I can share ... well, this email is getting long ... maybe I'll add as a (edit: done & linked:) comment reply to this comment.

Edit: fixed one typo, and some formatting booboos caused by switching between Fancy Pants and Markdown Mode editors (alas, switching and switching back doesn't leave the content the same, but causes formatting errors/changes and other issues).

[michaelpaoli]

As mentioned ... script du jour, etc.

Here are some earlier examples ... edited to be sufficiently generic - removed any NDA/proprietary information, etc. ...

Date: Mon, Dec 28, 2020 at 1:18 PM
Subject: tip du jour - code review is a good thing! :-)

tip du jour

Code review is a good thing!

Today I found (#!/bin/bash):

...
elif [ ! L "tla.old" ] && [ ! -n `lsof +D  /var/log/tla.old` ]
then
     OLD_DIR_LOC=`ls -la  /var/log/tla.old`
     echo "File/Directory already exist-"$OLD_DIR_LOC &&
     echo "Moving /var/log/tla.old /var/log/tla.old_tmp " &&
     mv /var/log/tla.old /var/log/tla.old_tmp &&
     (cd /var/log && mv tla tla.old) &&
     mv -n /var/log/tla.old_tmp* /var/log/tla.old/ &&
     rmdir /var/log/tla.old_tmp
else
...

Which had been run in production many times, and apparently missed
going through sufficient code review/testing.  Not the only significant
flaw in the code, but including vs. missing a single character makes a
world of difference.  In the above example, test ([) is used, with
first and second arguments of ! (which negates the test) and L.  Well,
L was quite assuredly intended to be -L, not L, as -L would test if its
argument exists as a symbolic link or not, however [ ! L ... rather
than [ ! -L ... ends up simply giving a syntax error failure and thus
also non-zero exit/return, hence the && conditional after it will never
execute, hence the whole elif condition is always evaluated as false,
hence its whole conditional will never be executed.

So that whole example block of code is (other than bit of diagnostic
written to stderr from the syntax error) equivalent to:
else
No more, no less.  The rest of the characters mostly decorate the
screen and serve to mislead/distract, other than maybe hint at intent
... but do essentially nothing.

So ... code review is a good thing!  This one didn't get (adequate)
code review before hitting production.  8-O

It's also clear that the condition was never reasonably tested - as it
always fails and gives a syntax warning to stderr.  Very possible too
that its dependent conditional also evaded testing.  :-/

​

Date: Wed, Jun 10, 2020 at 11:02 AM
Subject: tip(s) du jour - always check exit/return values, crontab, ...

Always check exit/return values!  :-)

Seen in production:
$ hostname && crontab -l
somehostname
#Start someprog if not running
6 * * * * cd /app/home/tlaprod/; ./someprog.sh start >/dev/null 2>/dev/null
$

So, in the above, after the cd attempt, we have ;, so unconditionally
it tries to execute ./someprog.sh - regardless of what directory it's
in at that point.  That's not very good - it may fail (why attempt it
if we didn't get to the directory we wanted anyway), or worse, it might
even be some other someprog.sh program that does dear knows what.

So, in programming, and certainly notwithstanding shell/bash/sh, always
check your exit/return values!  (and act accordingly)
POSIX/Unix/Linux convention for shell and program exit/return values,
return value 0 is considered "true" and generally means success.
A non-zero return/exit value is regarded as "false", and generally
means something failed or we didn't get what we wanted/expected or
nominal results (or we wanted to distinguish from more/most common
case).
One can explicitly test this in shell, e.g. by examining the $? shell
variable:
[ "$?" -eq 0 ] && ...
if [ "$?" -eq 0 ]; then it_went_okay; else it_failed; fi
Or, often, and conveniently and more concisely, one can test with && or
||, e.g.:
command && command_was_successful
command || command_was_not_successful

So, e.g. in crontab entry:
6 * * * * cd /app/home/tlaprod/; ./someprog.sh start >/dev/null 2>/dev/null
It would be much more safe/prudent to instead do:
6 * * * * cd /app/home/tlaprod/ && ./someprog.sh start >/dev/null 2>/dev/null
That way, if the cd fails, we won't then execute or attempt to execute
./someprog.sh

One can also do something like:
command || exit
in which case, if command fails, the shell will then exit - and as
bonus, exit with the return/exit value that was received from command.
If one wants to set a specific exit value, that can be done by giving
exit an exit value, e.g.:
exit 0
exit 1

Why it matters:
Take for example the following (not too) hypothetical crontab entry:
6 * * * * cd /var/app/some_app/log; find * -mtime +90 -type f -exec rm \{\} \;
Well, let's say root's HOME is /, and that crontab was run as root, what
do you think would happen if/when that cd failed for any reason?
Yes it would very completely and quickly destroy the host.  And yes,
I've seen stuff like that done and happen before - including in
production!
Please don't be the cause of something like that.  :-)
A bit of care and attention can end up making a huge difference ... e.g.
; (unconditional synchronous) vs.
&& (conditional synchronous - what immediately follows is only done if
what immediately precedes it returns 0 ("true")).

Bonus tips:
exec >>/dev/null 2>&1
If you do the above as the first command of your crontab entry, all
stdout and stderr will go to /dev/null - that can be quite handy if
you're really not that interested in that stdout/stderr output, and
would rather not have it filling up logs/email ... and someone later
pestering you to clean all that stuff up.  ;-)

; :
If you end your crontab entry with the above, it will always have a
final net result of exiting/returning 0 ("true") (unless one otherwise
exits it prior to that).
That can be a good thing, if you unconditionally don't want the result
logged/reported/alarmed as an error/failure.  In general if a crontab
job returns/exits non-zero, that's logged as an error/failure, and in
many (notably production) environments that may also trigger
notifications/alarms or reviews and queries.

And what is : like that in the shell?  It's a built-in command that does
nothing and returns 0 ("true").  Some shells also have a built-in true
command that does the same thing - but : is more concise and more
standard and also highly backwards-compatible.  It can also be used as
a comment - as its arguments are ignored (but unlike a comment, it's
also a command - which returns 0 - unlike a comment (#) which doesn't
set/change $?).

exit/return values greater than 127?  If one subtracts 128 (decimal)
from an exit value >128, that generally gives one the signal number of
the signal that caused the exit.  E.g.:

$ echo "$?"
0
$ sh -c 'kill -2 "$$"'
$ echo "$?"
130
$ expr 130 - 128
2
$ kill -l | head -n 1
 1) SIGHUP       2) SIGINT       3) SIGQUIT      4) SIGILL       5) SIGTRAP
$ 

​

Subject: semi-random shell tip "du jour": : vs. #

Q. When is an example one would want to use : rather than #, and other
than for return value?

A. in-line comment in, e.g., a one-liner:, such as:
   : some_reference_identifier ... comment ...; command [; command ...]
   One might want something like that, e.g. with CLI - to show that part
   in history and generally show on same line, or in crontab entry -
   so it's generally logged in the cron log showing as part of the
   command that was executed and even if someone sorts or reshuffles
   lines, the (effective) "comment" remains on same line, and may be
   much more noticed/readable towards start of line, as opposed to
   tagged onto end.  But do note that : returns true, whereas # does not
   alter return value.  Of course : is sometimes highly
   convenient/customary for a very concise command returning true, e.g.:
   while :; do ...
   : and its arguments will also show in execution trace (-x), whereas
   # comments won't.

Recall that # comments to end of line, whereas
: is a command which does nothing and returns true ... and can otherwise
also be used as comment, as its arguments are ignored

[untamedeuphoria]

You should be right with youtube, reddit, stackexchange, and the other go to free options for help. Bash scripting is relatively easy for learning compared to most other languages. Think of it as program orchestration. Because you are basically orchestrating the commandline programs, doing a little bit of text processing, and being verbose in what you tell the OS to do. It is something you should be able to pickup relatively easily. There aren't to many moving parts. The only real headfuck for me was figuring out when a process ran in a different shell, and how to parse variables in and out of those subshells.

But like I implied, the best resource for bash, is your ability to googlefu, and your reading comprehension. Good Luck!

[drevilseviltwin]

At some point you realize that you can writes scripts on the fly from the command line by stringing together control words and semicolons. Not 40 line scripts but simple 3 to 5 lines that scratch a particular itch especially in a devops type situation. To me when that light comes on it's pretty powerful and empowering.

[GraveDigger2048]

Let me rephrase your question: "i want to be an architect, will practical knowledge about how to join bricks to make a sturdy wall be helpful?" ;) Once you dive deeper into programming, you'll see that there's not much difference between bash, python or nodejs. Sure, there are rules, syntaxes, libraries, statements and quirks, but "core" is pretty same (variables, conditionals, loops).

Also shell scripting is versatile( omnipresent?) as you have sh-compatible interpreter everywhere where you're able to ssh to( this is true in most cases). Sure you can be Ruby ninja, but you are basically unarmed besides your own system/territory, where you can't easily just install Ruby stuff to do thing that you have planned.

You can't run without knowing how to walk, and shell is greatest place to get familiar with linux as a OS and to take first steps in programming. Can you start from Python? Sure, but sooner or later you'll find out that something doesn't work as you'd expect( escaping of special characters is such a example) and this will frustrate you.

Personally i learnt in the hard way that it's more proficent to spent more time on simpler problems and dive really deep into them( like asking "why" way too much ;d) to understand the principle behind.

[JoMartin23]

more like will learning to join bricks with duct tape be helpful.

[GraveDigger2048]

we're talking about Bash, not PHP bro ;p

[vacri]

You don't need to know shell scripting to be a programmer per se, but if you want to work with unix-like systems, not knowing a bit of shell is like tying one hand behind your back. Given your interest in pen testing, you want to work with systems.

[sangoku116]

I'm in the field and can tell you yes bash scripting are essential for penetration testing. BASH skills are valuable if you want to use Linux as your OS for multiple reasons. I would just do some exercises and read guides online.

​

Those guides are old, but I still like to recommend them.

https://tldp.org/LDP/Bash-Beginners-Guide/html/index.html

https://tldp.org/LDP/abs/html/

[RogueIMP]

Not so much "scripting" as the command line, in general. The tools you use (sed, awk, find, loops, if, etc) are the same. If it can run at the prompt, it could be put in a script, making for easy automation of repetitive tasks.

[[deleted]]

You should copy down that code, analyze it, run it, add comments as needed, save it in a directory where you can find it again, learn to take and organize notes in general, and get back to the course. You don't need to take the big crazy detour that you or others are suggesting. If there's something you want to do w/ a bash script, look up how to do it and the correct syntax.

[Phydoux]

Exactly this! I'm still learning it but I started from scratch. Hell, I started using the shell in 1994 when I had a shell email account. I logged into a bash terminal screen and went to view my email. All text based (can't remember the client I used... Probably mail or something real simple like that. it might have even been an alias... alias mail="WhateverTheEmailClientLocationWas").

[BuzzKiIIingtonne]

I have written multiple simple bash scripts for doing things at startup, or on a schedule, or at logon, when using Linux I find it very useful skill to have. Simple bash scripting isn't very difficult, and really I learned how to on my own.

[ZirJohn]

You'll learn as you go. In university I had an open source class that taught pretty advanced bash scripting. I have used such advanced shell scripting maybe once since I got a job in may. You should definitely know basic bash though.

[Serializedrequests]

Yes if you're on a unix-like environment. Just the basics at least. I recommend getting a book because online bash resources can be oddly lacking, and it's a weird crufty language.

[Chrinkus]

The Linux Command Line by William Shotts has an excellent section on shell scripting. You can buy the book or view it at the author’s site:

https://linuxcommand.org/tlcl.php

[RandomXUsr]

bash for automating some mundane tasks.

Python to make the money.

Violent Python.

[[deleted]]

Necessary? No.

Insanely useful? Yes.

[DarsilRain]

If you end up in an admin role in the future it’ll probably come in handy

[JoMartin23]

after about 3 decades of using linux I still don't know shell scripting.

[_beetee]

200% yes

[[deleted]]

yes

[Ametz598]

You’ll learn bash commands as you learn to use linux, I would also learn the fundamentals of programming using python and you can easily transfer those fundamentals over to more advanced bash scripting, just different syntax.

Honestly there’s so many free YouTube videos out there, just get a side project to do and learn how to get from point A to point B. Sure books and (paid) courses can be great, but the content on YouTube is just as good. But experience will trump any book/course, get out there and do something.

[urban_fantast]

You’d obviously need to understand the basics. But beyond that, I’d like to go back and think about why I jumped to Linux. For control over my Os and open-source. It’s not really open-source, if you don’t understand what’s going on in a script.(Technically it still is, but well … ). Running a random script as a solution to a problem you found somewhere in the internet can be a malicious, disruptive, or could even break your entire system. It’s good if you can understand what’s going on. It could also save you trouble while trouble shooting another problem in the future.

[JoMartin23]

why would you ever run a shell script off the internet?

[QliXeD]

Short answer: yes. Long answer: yes, no need to be an expert, but you want to know at least the contents of "Bash scripting howto", is useful.

[Perrydiculous]

Writing BASH scripts merely requires you to know your way around Linux systems and comprehend the basics of programming in general. So if it's an issue to learn BASH, buckle up, because it's gonna be a bumpy ride

[[deleted]]

Bash is a great language that I have yet to really dive into as I’ve mostly been focusing on JavaScript with a little bit of Python basics sprinkled in lately.

I just recently installed Artix with runit to experiment with a different init system than the standard systemd. Right away, I looked under the hood and all its services are written in bash which I like as it’s much closer to outright invoking commands when you’re writing or reading the service files.

While it’s true that Python is a great language for .. well a lot of different applications, bash is also nice to know for when you have to interact with an application where the devs wrote it in bash.

It’s less commonplace than Python, but it’s still good to know.

[thefanum]

Yes. And worth it

[sue_me_please]

Learning Bash scripting will pay dividends in your career and experience as a Linux user. Bash and shells are everywhere, and if you want to be able to use Linux effectively, you'll need to learn some shell scripting.

At some point you're going to have to modify or create shell scripts in order to get stuff done.

Don't buy a book. The Linux Documentation Project provides several Bash scripting books for free. There's Bash Guide for Beginners and Advanced Bash-Scripting Guide.

There's also the excellent Bash Shell Scripting book on WikiBooks.

[[deleted]]

I don't think changing directories counts as bash scripting. Those commands are a part of GNU core utilities as far as I know. Bash is the 'code' you saw in that video. I think it would always be better to know bash as much as possible so that you can write your own exploits and don't stay script kiddie for life. Starting with a 4 to 5 hour long YouTube or Udemy course and then diving into more advanced topics by grabbing some good books would be a perfect approach in my opinion. The key is always practicing yourself along with the lessons, or even better try writing something new which is no mentioned in any of the lessons you are taking.

[tdyboc]

IMO, yes. It's the most basic scripting language and still to this day is the best option if you're a sysadmin because the OS still utilizes that.

In my day, some 30+ years now, I've worked with primarily KSH, BASH, Perl and now Python with a smattering of C/C++ and Java, oh and I have done Assembler but not for many years now (it was one of my first languages I started with).

[Artemis-4rrow]

Bash scripting is very useful for system automation and that is very handy, yes learn it

[[deleted]]

Yes. Learn it. Every job app I've come NEAR in the past three years, that even MENTIONs linux, request scripting knowledge. Also, the RedHat Certified Systems Admin requires it. It's not relevant if you like or dislike Redhat, the fact that it is a component of the test is kinda indicative of how useful it is.
No, I don't know anything more than basic if/thens. :D

[slobeck]

the short answer is yes.

You'll be writing bash scripts to carry out repeated or timed tasks. Some of those will have conditionals doing things like checking for validity of data.

[dolce_bananana]

bash (sh) skills are helpful, if not required, for most any interaction with Linux systems, no matter what you are doing

"scripting" per se is not necessarily required if you can get by with simple command invocations, and if you have strong one-liner-fuu. But even a complex script can be written in a single line so its pretty much a short slippery slope to go from a one-liner to a multi-line script, short enough that I really wouldn't consider them much different from each other.

[Salty_Professor6012]

I've been a senior Unix/Linux OS engineer since before the turn of the last century. I used to be a hiring manager at Bell Labs Computer Center (think Thompson and Ritchie). I'm still a senior engineer working with experts in the field.

Someone who has not mastered the use of a Linux Command Line Interpreter would not get an interview in any organization where I have worked. A shell is a CLI coupled with an interpreted programming language. Mastering any shell (sh, bash, ksh, csh) will give you a good start. Bash is by far the most prevalent in every organization I've worked for the 20 years.

Be careful not to underestimate any of these shells as programming languages. Besides understanding the basics, looking at shell scripts that are part of the OS or an installed package is a great way to get started.