[SOLVED] Things NOT to do when helping as a newbie
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
It takes time to get comfortable with bash. I don't try to do fancy scripting with bash. Programming languages seem to have a similar thought process to them from my limited experience with them. I haven't played with Python. I tried Godot for fun which is supposedly like Python. I was confused because it used indentions instead of brackets to denote nesting of functions.
Firstly welcome to Linux, Slackware and LQN, ul7. I've rather enjoyed your posts so don't over analyze too much, especially since your desire to help and learn are both quite evident. I'm sure you've already seen by now that no matter what level we may think we are, we will make mistakes, misinterpret, etc and nobody knows it all anyway.
I really like the well thought out post that upnort has offered and I'd like to offer a caveat and emphasis on this line
Quote:
Originally Posted by upnort
* Step away when a post triggers any kind of emotional response. Do not reply until the emotional trigger subsides.
Here's a little anecdote to illustrate. Back 20 years ago when I started using Linux I spent a lot of time on various IRC channels asking questions. In those days one had to configure just about everything, including modems, manually, and even their permissions. I hadn't got that far yet and the only way to get online then to find the answers was to start a session as root. Many IRC clients note if someone is logged in as root and despite my asking how to fix that one guy gave me the pat response for newbs RTFM!.
I actually responded politely if a tad defensively to which he replied "It's not my fault you have a ghetto box"
Naturally, I immediately listed off all m y leet hardware (that is actually more my field) to which he fired back "I'm not talking about your hardware. I'm talking about YOU! You're a ghetto admin!"
I was really upset, hurt and a whole host of negative emotions, made some excuse and signed off. The more I thought about it the angrier and more hurt I got.
Then, it hit me. He was right! I'd jumped into the deep end before knowing how to swim properly. I swore to never be that uninformed ever again and immediately went to CompUSA and bought O'Reilleys "Running Linux" and "Linux in a Nutshell" and a few more about Linux Administration. One of the reasons I'm offering this anecdote is, as you may recall, I recommended those O'Reilley books to you. Ripples, right?
Yes the guy was brutally blunt but had I stayed triggered who knows if I'd even stuck with Linux. Because I got reasonable and analytical fairly soon, I grew. I'm no Linux expert, just know a few things, but like you, I enjoy helping. I try to explain my level of confidence in any help I attempt so as not to throw off the guy asking for help, or inflate my ego as some kind of poser, and I especially try to not get triggered.
You seem sincere and honest and hungry to learn. With that on your side You will do just fine.
TLDR - We can even learn from some jackasses if we don't waste time being triggered or becoming one ourselves.
Firstly welcome to Linux, Slackware and LQN, ul7. I've rather enjoyed your posts so don't over analyze too much, especially since your desire to help and learn are both quite evident. I'm sure you've already seen by now that no matter what level we may think we are, we will make mistakes, misinterpret, etc and nobody knows it all anyway.
I really like the well thought out post that upnort has offered and I'd like to offer a caveat and emphasis on this line
Here's a little anecdote to illustrate. Back 20 years ago when I started using Linux I spent a lot of time on various IRC channels asking questions. In those days one had to configure just about everything, including modems, manually, and even their permissions. I hadn't got that far yet and the only way to get online then to find the answers was to start a session as root. Many IRC clients note if someone is logged in as root and despite my asking how to fix that one guy gave me the pat response for newbs RTFM!.
I actually responded politely if a tad defensively to which he replied "It's not my fault you have a ghetto box"
Naturally, I immediately listed off all m y leet hardware (that is actually more my field) to which he fired back "I'm not talking about your hardware. I'm talking about YOU! You're a ghetto admin!"
I was really upset, hurt and a whole host of negative emotions, made some excuse and signed off. The more I thought about it the angrier and more hurt I got.
Then, it hit me. He was right! I'd jumped into the deep end before knowing how to swim properly. I swore to never be that uninformed ever again and immediately went to CompUSA and bought O'Reilleys "Running Linux" and "Linux in a Nutshell" and a few more about Linux Administration. One of the reasons I'm offering this anecdote is, as you may recall, I recommended those O'Reilley books to you. Ripples, right?
Yes the guy was brutally blunt but had I stayed triggered who knows if I'd even stuck with Linux. Because I got reasonable and analytical fairly soon, I grew. I'm no Linux expert, just know a few things, but like you, I enjoy helping. I try to explain my level of confidence in any help I attempt so as not to throw off the guy asking for help, or inflate my ego as some kind of poser, and I especially try to not get triggered.
You seem sincere and honest and hungry to learn. With that on your side You will do just fine.
OK, yeah man! I remember now, I was talking to MLanden on irssi last night about this nice guy hooking me up with some books.
I was like "OMG I feel so bad I can't remember his name!" LMAO. So embarrassing.
I'm actually reading the "Learning the UNIX Operating System" from O'Reilley right now.
I got those those other two books you gave me in the "old queue". I'll remember you now enorbet. True confessions man....thanks a million. lmao...
So bash is both an interpreter and language respectively, which was written in C?
*head explodes*
Damn, Brian Fox is a beast. So is Dennis Ritchie.
Bash implements a language called bourne shell script named after Stephen Bourne who wrote that shell in the 70s. You wouldn't really talk about there being a bash language. Bourne shell script is the language. Now, bash does also include features from David Korn's ksh shell and csh or tcsh (Bill Joy, BSD), as well as stuff it threw in itself, but it's not talked about as a new language, but rather as a bunch of non-standard extensions. Maybe someone might talk about doing "bash scripting" but never "the bash language."
What I suspect Didier is warning you about by suggesting that you read the POSIX document is to avoid the notorious "bashisms" (not so notorious among Linux people?). These are features that will only work when your script is run by bash. Other shells (ksh, ash, dash, ...) that also have the bourne shell subset will not understand your script. It's okay to use bashisms of course, but you should come to know when you've written a script that's only runnable in bash vs. one any bourne compatible shell can run. If you ever decide to run BSD you'll want to disavow bash most likely, though, so if that's a possibility maybe you want to either stick to the Bourne Shell core features or a common subset of Bash and ksh features.
Reading standards documents might be a bit dry. I'd suggest The Unix Programming Environment by Kernighan and Pike. Be warned there are one or two trivial matters in the first chapter that apply only to very early UNIX systems like System 7 and that, if you're intolerant of such things, might give a first impression that the book is antiquated. But with that out of the way the rest of the book is 100% relevant and not dated at all. It has the advantage, as they write in the intro, of not overwhelming you with detail but giving you the essential matter in a tutorial way, so you don't mistake trees for forest. And the shell scripting is entirely bourne shell.
So from there if you read one of the many bash tutorials online perhaps you'll know what bashisms are and perhaps can abstain from needlessly using them in contexts where that might matter. Then again, if you don't you're in good company. It seems that much of GNU userland cannot be built, or at least its tests can't be run, without using bash specifically as your /bin/sh. (I've found this out the hard way recently by trying to substitute in OpenBSD's ksh for bash as /bin/sh when going through Linux from Scratch. Had to undo that in a hurry.)
There's also a really good book by David Korn on his shell: The New Korn Shell. What that covers is pretty relevant to bash too, since bash took more from ksh than any other shell. But he goes even further than bash in the devil may care non-portability sense, telling you to get away from "obsolete" language constructs in favour of better ones in his shell. E.g. his shell tells you to use == for string comparisons while the shell style and syntax checker shellcheck will tell you to use = instead for portability. Not sure I would use shellcheck right away, but later you might learn a lot from using it and reading its explanations for its multitudinous criticisms of people's code.
Bash implements a language called bourne shell script named after Stephen Bourne who wrote that shell in the 70s. You wouldn't really talk about there being a bash language. Bourne shell script is the language. Now, bash does also include features from David Korn's ksh shell and csh or tcsh (Bill Joy, BSD), as well as stuff it threw in itself, but it's not talked about as a new language, but rather as a bunch of non-standard extensions. Maybe someone might talk about doing "bash scripting" but never "the bash language."
What I suspect Didier is warning you about by suggesting that you read the POSIX document is to avoid the notorious "bashisms" (not so notorious among Linux people?). These are features that will only work when your script is run by bash. Other shells (ksh, ash, dash, ...) that also have the bourne shell subset will not understand your script. It's okay to use bashisms of course, but you should come to know when you've written a script that's only runnable in bash vs. one any bourne compatible shell can run. If you ever decide to run BSD you'll want to disavow bash most likely, though, so if that's a possibility maybe you want to either stick to the Bourne Shell core features or a common subset of Bash and ksh features.
Reading standards documents might be a bit dry. I'd suggest The Unix Programming Environment by Kernighan and Pike. Be warned there are one or two trivial matters in the first chapter that apply only to very early UNIX systems like System 7 and that, if you're intolerant of such things, might give a first impression that the book is antiquated. But with that out of the way the rest of the book is 100% relevant and not dated at all. It has the advantage, as they write in the intro, of not overwhelming you with detail but giving you the essential matter in a tutorial way, so you don't mistake trees for forest. And the shell scripting is entirely bourne shell.
So from there if you read one of the many bash tutorials online perhaps you'll know what bashisms are and perhaps can abstain from needlessly using them in contexts where that might matter. Then again, if you don't you're in good company. It seems that much of GNU userland cannot be built, or at least its tests can't be run, without using bash specifically as your /bin/sh. (I've found this out the hard way recently by trying to substitute in OpenBSD's ksh for bash as /bin/sh when going through Linux from Scratch. Had to undo that in a hurry.)
There's also a really good book by David Korn on his shell: The New Korn Shell. What that covers is pretty relevant to bash too, since bash took more from ksh than any other shell. But he goes even further than bash in the devil may care non-portability sense, telling you to get away from "obsolete" language constructs in favour of better ones in his shell. E.g. his shell tells you to use == for string comparisons while the shell style and syntax checker shellcheck will tell you to use = instead for portability. Not sure I would use shellcheck right away, but later you might learn a lot from using it and reading its explanations for its multitudinous criticisms of people's code.
I find that really interesting how people take things and make it their own. This is the beauty of Open Source. UNIX I'm sure after all was built for experts. They needed something to fit their needs and have flexibility. It seems the history has reflected that successfully. Thank you for this read. Dryness does not bother me at all on reading material. I read RFC's all the time for networking, so that's about as dry as it gets. These threads will prove useful in keeping me busy, which will not go to waste, I assure you.
You can do whatever you want except calling me Dude. Thanks.
I may have called someone dude at one point, I'll try not to do it again.
But I don't know what other title is appropriate. I know ghetto admin here has called me bro in one thread, even though nobody else calls me that.
Maybe you would prefer sir or madam, but that would mean you're pulling a rank. If you're a NATO officer I may call you that, otherwise I don't know.
Isn't this like two Canadians shouting: I'm not your buddy, guy?
I may have called someone dude at one point, I'll try not to do it again.
But I don't know what other title is appropriate. I know ghetto admin here has called me bro in one thread, even though nobody else calls me that.
Maybe you would prefer sir or madam, but that would mean you're pulling a rank. If you're a NATO officer I may call you that, otherwise I don't know.
Isn't this like two Canadians shouting: I'm not your buddy, guy?
GUY. Ugh.......Yeah it's a terrible habit I have with saying "dude". I'm glad he mentioned something, because there is a person here at work that says, "Hey! Hey guy! You doin' OK guy?!" I just acknowledge and try to get away ASAP. So much appreciated, @ upnort!
@ul7
Things can sometimes be impersonal can't they? You can always use our screen names
Gordie! Just want to give you a personal thank you for everything thus far. I sincerely apologize for taking things too personal. You have been very inspirational to me and I aim to heed your advice and other fellow veterans in this community. I have actually been reading more about the history behind Slackware (like I should have in the first place). Now it's all starting to make sense. So once again, thank you.
EDIT: By "making sense" I really mean the overall goal of the product. From what I've gathered so far, this OS is designed for stability and reliability (correct me if I'm wrong). Which those things cannot be rushed. It has to go through a rigorous trial of development and testing before releasing it to a "stable" status right? I may not be 100% right on this, but regardless this is why the culture here is very "learn and grow" vs. "search and rush." I may edit that last part if I think of a better comparison lol, but I think I get it so far.
@ul7 Thank you for your kind words my friend. Your enthusiasm has proven to be infectious. Have you seen the view count of this thread? You are living proof that Slackware is not a barrier to a new Linux user.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.