Career Goals - Futures in Linux Careers
-
@scottalanmiller said in Career Goals - Futures in Linux Careers:
@nerdydad said in Career Goals - Futures in Linux Careers:
@wirestyle22 said in Career Goals - Futures in Linux Careers:
The Linux Command Line: A Complete Introduction by William E. Shotts Jr
From talking with you before, you've been working on this for sometime now. Do you continually reference this book or did you read it to learn and then never touched it again?
I used a command line book for UNIX and Bash in 1994 and have never used one since. I got the basics, now I just look up specific commands online.
Yeah. Those books get quite complex though. Bash can do a lot as you know.
-
@wirestyle22 said in Career Goals - Futures in Linux Careers:
@scottalanmiller said in Career Goals - Futures in Linux Careers:
@nerdydad said in Career Goals - Futures in Linux Careers:
@wirestyle22 said in Career Goals - Futures in Linux Careers:
The Linux Command Line: A Complete Introduction by William E. Shotts Jr
From talking with you before, you've been working on this for sometime now. Do you continually reference this book or did you read it to learn and then never touched it again?
I used a command line book for UNIX and Bash in 1994 and have never used one since. I got the basics, now I just look up specific commands online.
Yeah. Those books get quite complex though. Bash can do a lot as you know.
BASH is a pretty basic programming language. It has very few constructs. Pipelines, standard IO, a few really basic data constructs, that's all that there is to know. It's a "learn in a day" kind of language.
-
@scottalanmiller said in Career Goals - Futures in Linux Careers:
@wirestyle22 said in Career Goals - Futures in Linux Careers:
@scottalanmiller said in Career Goals - Futures in Linux Careers:
@nerdydad said in Career Goals - Futures in Linux Careers:
@wirestyle22 said in Career Goals - Futures in Linux Careers:
The Linux Command Line: A Complete Introduction by William E. Shotts Jr
From talking with you before, you've been working on this for sometime now. Do you continually reference this book or did you read it to learn and then never touched it again?
I used a command line book for UNIX and Bash in 1994 and have never used one since. I got the basics, now I just look up specific commands online.
Yeah. Those books get quite complex though. Bash can do a lot as you know.
BASH is a pretty basic programming language. It has very few constructs. Pipelines, standard IO, a few really basic data constructs, that's all that there is to know. It's a "learn in a day" kind of language.
For you maybe. Not for me
-
@wirestyle22 said in Career Goals - Futures in Linux Careers:
@scottalanmiller said in Career Goals - Futures in Linux Careers:
@wirestyle22 said in Career Goals - Futures in Linux Careers:
@scottalanmiller said in Career Goals - Futures in Linux Careers:
@nerdydad said in Career Goals - Futures in Linux Careers:
@wirestyle22 said in Career Goals - Futures in Linux Careers:
The Linux Command Line: A Complete Introduction by William E. Shotts Jr
From talking with you before, you've been working on this for sometime now. Do you continually reference this book or did you read it to learn and then never touched it again?
I used a command line book for UNIX and Bash in 1994 and have never used one since. I got the basics, now I just look up specific commands online.
Yeah. Those books get quite complex though. Bash can do a lot as you know.
BASH is a pretty basic programming language. It has very few constructs. Pipelines, standard IO, a few really basic data constructs, that's all that there is to know. It's a "learn in a day" kind of language.
For you maybe. Not for me
Likely you are thinking of something other than BASH then. BASH is very simple.
-
The hardest thing in BASH is learning the evaluation options, and those you just look up in a table.
-
Once you know > >> < | plus sourcing, if and for... you are basically done.
-
@scottalanmiller said in Career Goals - Futures in Linux Careers:
Once you know > >> < | plus sourcing, if and for... you are basically done.
With BASH, yes.
Learning
sedorawkare rather more difficult. You need to learn regular expressions, which aren't quite standard. Once you do learn them, shells and scripting are a lot easier and faster. -
@travisdh1 said in Career Goals - Futures in Linux Careers:
@scottalanmiller said in Career Goals - Futures in Linux Careers:
Once you know > >> < | plus sourcing, if and for... you are basically done.
With BASH, yes.
Learning
sedorawkare rather more difficult. You need to learn regular expressions, which aren't quite standard. Once you do learn them, shells and scripting are a lot easier and faster.Certainly, but those aren't BASH and are used identically regardless of the calling shell. SED is a text processor application, AWK is a competing programming language.
-
@scottalanmiller said in Career Goals - Futures in Linux Careers:
@travisdh1 said in Career Goals - Futures in Linux Careers:
@scottalanmiller said in Career Goals - Futures in Linux Careers:
Once you know > >> < | plus sourcing, if and for... you are basically done.
With BASH, yes.
Learning
sedorawkare rather more difficult. You need to learn regular expressions, which aren't quite standard. Once you do learn them, shells and scripting are a lot easier and faster.Certainly, but those aren't BASH and are used identically regardless of the calling shell. SED is a text processor application, AWK is a competing programming language.
I know it's difficult to remember what a thread is supposed to be, but we're not discussing BASH here, but what someone should be learning.
I am guilting of using AWK as nothing more than a text processor most of the time, so it lives right alongside SED in my head.
-
@travisdh1 said in Career Goals - Futures in Linux Careers:
@scottalanmiller said in Career Goals - Futures in Linux Careers:
@travisdh1 said in Career Goals - Futures in Linux Careers:
@scottalanmiller said in Career Goals - Futures in Linux Careers:
Once you know > >> < | plus sourcing, if and for... you are basically done.
With BASH, yes.
Learning
sedorawkare rather more difficult. You need to learn regular expressions, which aren't quite standard. Once you do learn them, shells and scripting are a lot easier and faster.Certainly, but those aren't BASH and are used identically regardless of the calling shell. SED is a text processor application, AWK is a competing programming language.
I know it's difficult to remember what a thread is supposed to be, but we're not discussing BASH here, but what someone should be learning.
I am guilting of using AWK as nothing more than a text processor most of the time, so it lives right alongside SED in my head.
It was specifically brought up that BASH is hard and complicated and would take a long time to learn. My point was that it was not and that if he thought that it was, that he might be confusing other things (like AWK) with BASH. So it was totally the point.
And even if you don't think of AWK as a language, but as an application, that's till my point - it's in no way BASH. It works the same on PowerShell, on CMD, on ZSH, as on BASH. It's an application.
One of the things that makes BASH seem hard to people is they think that every application opened using the command line is part of the command line. It would be like installing some software on Windows, and confusing that with Windows. And if that application you installed was hard, thinking that Windows was hard because Windows was used to call it.
-
So mashing those things together derails people from learning, because they aren't even clear what they are using, what it does, where to find resources. It might see pedantic, but pedantisism is often the difference between finding the world simple and obvious, or hard and confusing. Learning BASH when you don't know what it is is really hard, learning BASH when you know what it is is really easy.
And there is a reason that books on BASH don't teach SED and AWK, they aren't BASH. And that's why there are books just for SED and AWK. You have to know which is which just to know which books to look to for answers.
-
Loved using DOS, but now prefer using bash rather then powershell.. I just don't get why every command is like writing a sentence in powershell.
-
@nerdydad said in Career Goals - Futures in Linux Careers:
I really don't have any career goals in life. I'm a SysAdmin which I am pretty happy with. Like the job and the company. No complaints there (in case the boss is looking <sssshhh>). I have always known that I wanted to work in computers coming out of high school. Went into college and I was able to cross out a few choices, such as software development and web design. I had considered networking because I wanted something that challenged both my brain and my body. Well, my brain gets challenged, but not so much my body anymore.
As of right now, I have been exposed to a variety of technologies (Hyper-V, VMware ESXi/vSphere, PowerShell, PowerCLI, Veeam B&R/ONE, basic networking technologies [routers, switches], and a little bit of everything in between). However, I am a little bit of a control freak. While I know that nobody can exactly predict the future, I do believe that we can tell where we are going from where we have been. While I like my job, I want to be challenged more and exposed to even more technologies, such as networking routing and switching, and VoIP. I especially want to focus my efforts to Linux servers, pushing more towards Fedora server (no real reason of my own). I see that there is KVM and LXD and Kubernetes and OpenNAP. Still not totally interested in DevOps, but don't mind automation (such as CHEF or Terraform) in order to increase efficiencies.
So, after that BIG long spiel, where does the major contenders on ML see Linux being in 5 years? That is where I would like to be.
You sound similar to I as far as wanting to be exposed to many things. The challenge for me is deciding on what to learn and when.
-
@stuartjordan said in Career Goals - Futures in Linux Careers:
Loved using DOS, but now prefer using bash rather then powershell.. I just don't get why every command is like writing a sentence in powershell.
Because .... no I don't have a reason, either. Maybe it's because I started on BASH (well, Shell, that BASH came from) in the 1980s and just "get it" after all this time. But PS seems so convoluted unnecessarily. BASH is slow clean and easy.
-
@scottalanmiller haha 100% agree
-
@scottalanmiller said in Career Goals - Futures in Linux Careers:
One of the things that makes BASH seem hard to people is they think that every application opened using the command line is part of the command line. It would be like installing some software on Windows, and confusing that with Windows. And if that application you installed was hard, thinking that Windows was hard because Windows was used to call it.
OK this makes sense. But it's even more challenging for noobs when the thing they are calling is included in the OS.
Sure Wordpad isn't part of Windows itself - it's a separate app, but it comes installed with Windows, so end users don't really see it as any different. Now when you're talking about MS Office Word - that's installed separately and on purpose, so users tend to understand that it's not part of Windows.I don't know if awk and SED are or are not installed in most Linux distros or not, but assuming it is, that would explain the lack of understanding that launching SED is not yet just another command that's part of BASH.
-
@dashrender said in Career Goals - Futures in Linux Careers:
I don't know if awk and SED are or are not installed in most Linux distros or not, but assuming it is, that would explain the lack of understanding that launching SED is not yet just another command that's part of BASH.
That's VERY different, though. SED, AWK, and BASH are all apps included in a typical Linux distro. Just as PerfMon, Notepad, and PowerShell are all included in Windows.
So if you are merging AWK and BASH, why not call PerfMon PowerShell?
In your example, you are treating Windows and Linux completely differently. BASH is just one of many apps included with a typical Linux install, and some Linux installs (many, in fact) don't include BASH at all, but they still have AWK and SED. But no Windows comes without both PerfMon and PowerShell.
Do you see why that logic doesn't make sense as it is not consistent from place to place? If you were saying that AWK seemed like it was "part of Linux" and that WordPad seemed like "part of Windows" because they were included in them, then sure, I can see that.
But mixing multiple things together because they are all peers within the same parent container doesn't make sense. That's like confusing apples with bananas simply because they were sold in the same grocery bag.
-
@dashrender said in Career Goals - Futures in Linux Careers:
.... SED is not yet just another command that's part of BASH.
BASH is a programming language. The only "commands" it has are programming language control structures. Shells aren't full of commands.
BASH commands are extremely few like **for, if, . (it's just a dot but is called source), export, read, alias, ....
All programming stuff, not things people using BASH typically type at all. BASH has two key uses...
- Run other programs
- Control the input and output to those other programs
That's it. Think of DOS. DOS was just a way to load applications, DOS itself did almost nothing, and DOS was the entire OS plus a shell. BASH is only the shell. A typical BASH user will use literally zero bash commands. And advanced BASH users will typically use four or five.
For example, I use if and for all of the time. But that's about it.
-
Now, when taking this bit of the conversation and looping it back to careers, this is where we could say how important it is that IT people learn basic programming. Because it takes extremely little time programming, like a few days, before we can then simply explain that "BASH is a programming language" to make basically everything else really clear. Realizing that BASH is a programming language, it becomes obvious that things like top, AWK or cal (the calendar) are obviously applications being called from it, and not a part of it.
No programming language or shell anywhere has that stuff built in. For some bizarre reason, BASH has earned this weird reputation as being the cumulation of all software that can be run by an operating system.
But oddly, why does AWK or cal get confused as part of BASH, but not Rocket, MySQL, Microsoft SQL Server and other apps called identically?
-
@scottalanmiller said in Career Goals - Futures in Linux Careers:
@dashrender said in Career Goals - Futures in Linux Careers:
I don't know if awk and SED are or are not installed in most Linux distros or not, but assuming it is, that would explain the lack of understanding that launching SED is not yet just another command that's part of BASH.
That's VERY different, though. SED, AWK, and BASH are all apps included in a typical Linux distro. Just as PerfMon, Notepad, and PowerShell are all included in Windows.
So if you are merging AWK and BASH, why not call PerfMon PowerShell?
In your example, you are treating Windows and Linux completely differently. BASH is just one of many apps included with a typical Linux install, and some Linux installs (many, in fact) don't include BASH at all, but they still have AWK and SED. But no Windows comes without both PerfMon and PowerShell.
Do you see why that logic doesn't make sense as it is not consistent from place to place? If you were saying that AWK seemed like it was "part of Linux" and that WordPad seemed like "part of Windows" because they were included in them, then sure, I can see that.
But mixing multiple things together because they are all peers within the same parent container doesn't make sense. That's like confusing apples with bananas simply because they were sold in the same grocery bag.
There's a huge difference here that I feel you're glossing over. In Windows - you can super easily see that Perfmon is called perfmon in the window title and you're looking a gui interface for it.
when your 'running' BASH and you run an SED command inside BASH - it doesn't look any different.
I'll give you that people will have the same issue on Windows if they are in a CMD and they run powershell commands by typing something like "powershell.exe somecommand -somearguement" to a normal user that appears to be just part of CMD, not something special or external to CMD.
