Register
It is currently Thu May 24, 2018 7:20 pm

Writing a select statement in bash, input is always invalid


All times are UTC - 6 hours


Post new topic Reply to topic  [ 19 posts ] 
Author Message
 PostPosted: Sat Oct 08, 2016 3:32 pm   

Joined: Sat Oct 08, 2016 3:25 pm
Posts: 10
I'm working on the following script to validate something like a "Yes I'm sure" before installing a driver package, I'm experimenting with the code below, and it runs, but every time i try it, my input is always processed as if it's invalid. I've been staring at this code for two days and no matter what I change my input is always handled as invalid.

Code:
#!/bin/bash

echo "INSTALLER"
echo "THIS IS PROVIDED WITHOUT WARRANTY"
echo "ARE YOU SURE YOU WANT TO PROCEED?"
echo "I AGREE TO CONTINUE-QUIT TO EXIT"
options=("I AGREE" "QUIT")
select opt in "${options[@]}"
do
   case $opt in
      "I AGREE")
         echo "CONTINUTING"
         break
         ;;
      "QUIT")
         echo "QUITTING"
         break
         exit;;
      *) echo invalid option
         continue
         ;;
   esac
done


Last edited by VolumetricSteve on Sat Oct 08, 2016 7:06 pm, edited 2 times in total.

Top
 Profile  
 PostPosted: Sat Oct 08, 2016 6:53 pm   

Joined: Mon Oct 20, 2014 9:53 am
Posts: 574
First of all: Please use code tags and indent properly.
This is unreadable. Click "full editor"

The read about the bash internal command with help like so:
help select

Quote:
...The WORDS are expanded, generating a list of words. The
set of expanded words is printed on the standard error, each
preceded by a number. If `in WORDS' is not present, `in "[email protected]"'
is assumed. The PS3 prompt is then displayed and a line read
from the standard input. If the line consists of the number
corresponding to one of the displayed words, then NAME is set
to that word. If the line is empty, WORDS and the prompt are
redisplayed. If EOF is read, the command completes. ...


Top
 Profile  
 PostPosted: Sat Oct 08, 2016 7:15 pm   

Joined: Sat Oct 08, 2016 3:25 pm
Posts: 10
I had indented it, I didn't realize the formatting got lost when I posted it.
I read the manual, thanks, it got me where I am.


Top
 Profile  
 PostPosted: Sun Oct 09, 2016 4:16 pm   

Joined: Sat Oct 08, 2016 3:25 pm
Posts: 10
Someone in another forum pointed me in the right direction. I realize I just fundamentally misunderstood how "select" works. I thought it accepts a string from stdin and it would appear it does not. That 'help' text might as well be a passage from an ancient bible written in latin - looking back at it with what I know now, I still can't figure out what the author is trying to say.

Here's what matters in this case in plain English (to anyone else dealing with the same confusion):

'select' will build a numbered list of options from a list you provide. Example:
options=("option1" "option2" "option3")

when select is called in your script, it assigns a number to each item in that list and waits for matching user input. Example:
select opt in "${options[@]}"

The user will see a list of things to pick from, 1 through 3, an entry for each item you provided with options=(insert options here) The user would then enter 1, 2 or 3 as an answer to the prompt. In my usage scenario, i'm passing this off to a case-statment. Come to find out, the syntax is fine, I just thought it would parse a string and not a single digit. To get the behavior I had hope for, the "read" command should be used instead.


Top
 Profile  
 PostPosted: Sun Oct 09, 2016 11:04 pm   

Joined: Mon Oct 20, 2014 9:53 am
Posts: 574
What's wrong with that:
Quote:
The PS3 prompt is then displayed and a line read
from the standard input. If the line consists of the number
corresponding to one of the displayed words, then NAME is set


Top
 Profile  
 PostPosted: Mon Oct 10, 2016 1:21 pm   

Joined: Sat Oct 08, 2016 3:25 pm
Posts: 10
I find quite often the language used to write these snippits of help, or man pages, is incredibly unclear on the purposes of their word choices.

In the section you picked:
"The PS3 prompt is then displayed and a line read
from the standard input. If the line consists of the number
corresponding to one of the displayed words, then NAME is set"

If you're unfamiliar with the PS3 prompt, this is almost meaningless. While technically what they say is true, it's not laid out in a way that someone 'fresh-off-the-street' could handily make use of the information being conveyed. It also goes into something called "NAME" being set, what is NAME? Why is it being set?

My larger issue however, is with the whole section:

select NAME [in WORDS ... ;] do COMMANDS; done
Select words from a list and execute commands.

The WORDS are expanded, generating a list of words. The
set of expanded words is printed on the standard error, each
preceded by a number. If `in WORDS' is not present, `in "[email protected]"'
is assumed. The PS3 prompt is then displayed and a line read
from the standard input. If the line consists of the number
corresponding to one of the displayed words, then NAME is set
to that word. If the line is empty, WORDS and the prompt are
redisplayed. If EOF is read, the command completes. Any other
value read causes NAME to be set to null. The line read is saved
in the variable REPLY. COMMANDS are executed after each selection
until a break command is executed.

Exit Status:
Returns the status of the last command executed.

"the WORDS are expanded" seems to exist entirely without context, but somehow these WORDS which are expanded generating a list of words. This to me sounds like they intentionally wanted to make it hard to understand, but I'm sure that couldn't have been their actual intent. What does all-uppercase 'WORDS' mean? Then we're generating a list of all-lowercase 'words' with it? What?
The author thinks that the one line "select NAME [in WORDS ... ;] do COMMANDS; done" is enough context without example, but I disagree. Context isn't provided that disambiguates the purpose and utility of the syntax or the items worked on by 'select'

Knowing what I know now, if I had written it, I would have said something like "The Select statement needs a pre-defined list of one or more items. The user will interact with them to indicate a choice. A list of three items, represented here: Options=("option1" "option2" "option3") would work with the Select statement to prompt the user on Standard-Error output with the choice to select one of the three by asking for the number of the choice they want." etc etc, other details to be included as necessary.

These criticisms could be easily dealt with by demanding that the reader be more experienced or more learned in unix/linux scripting, but that presupposes that we wouldn't need help understanding the material in the first place.

ANYWAY, I just usually don't find these documents helpful due to either their lack of descriptive language or sparse explanations.


Top
 Profile  
 PostPosted: Mon Oct 10, 2016 3:39 pm   

Joined: Mon Oct 20, 2014 9:53 am
Posts: 574
You've got to get used to it.
This is the way how manpages are written.

All these words in all upper case are meaningful.
Read man man and man info

If they appear the first time, they define a kind of variable.
And later on they are referred to from text.
Some of them refer to basic syntax concepts of shells.
e.g. a list is a comma separated string.


Top
 Profile  
 PostPosted: Tue Oct 11, 2016 9:52 am   

Joined: Sat Oct 08, 2016 3:25 pm
Posts: 10
I see what you're saying, and I see a system that's stood and has been accepted for many decades. I can't help but also notice that the availability of internet resources can often act in replacement of these texts. In *all* cases when I have a linux/bash/unix, (etc) question, I will always check the internet before I try a manpage, if I must I'll fall back to the manpage. I think that speaks volumes of the readability of the information in them. I also think it's no coincidence that with more information becoming available in more digested forms, the popularity of linux has exploded as it becomes easier to use, in this case by lowering the barrier of self-education. While I agree it's the way manpages are written, I'm not as convinced I have to get used to it. I find it antiquated and really, if there's an easier way to do something...people will eventually just do whatever that is, instead. In some cases, we're stuck with them for now, but I think eventually they'll go the way of the Yellowpages.


Top
 Profile  
 PostPosted: Tue Oct 11, 2016 12:21 pm   

Joined: Mon Oct 20, 2014 9:53 am
Posts: 574
Long story short:
Manpages cover ALL the details and inner workings.

If you learned to read manpages, you are can understand evers little detail of the entire system.
The net gives always misleading advice, as sites are outdated pretty fast, and folks are proud and blog their "successes" on learning linux.


Top
 Profile  
 PostPosted: Tue Oct 11, 2016 5:05 pm   

Joined: Sat Oct 08, 2016 3:25 pm
Posts: 10
Quote:
Long story short:
Manpages cover ALL the details and inner workings.


This may or may not be true in all cases. At minimum, the manpage (or any document) is only as complete and polished as the author made it. Thousands of people have contributed to open source (and closed source for that matter) over the decades, I find it unreliable to assume they're all of the same caliber. I'd extend this to the quality of the descriptions and what you say about "ALL" the inner workings.

I invite you to take a look at 'man term' for example, which is kind of my go-to for exemplary vagueness. After reading this, I still don't know what "term" is, but I know it has a lot of parts, some of which have some documented interactions with other things, and some which don't.

"DESCRIPTION" appears blank, but in a subsection goes right into describing what parts of term, or perhaps the idea of term, can do. I'm sure this makes sense to someone, but it doesn't make sense to me. I'd like description to describe what 'term' is overall, what it's for, why it exists, what depends on it, what necessary function does it fulfill and so on.

Conversely, the manpage for man itself is actually pretty good. It meets its own criteria and it does an overall decent job of explaining why it's there, what it does, and how it works. It goes into multiple deep explanations and it appears that it leaves very little to the imagination. I do not get this same level of satisfaction from so...so many other man pages.

Quote:
If you learned to read manpages, you are can understand evers little detail of the entire system.


I'm sure this isn't true. Reasons: 1.What I mentioned earlier about the caliber of authors and the content given. 2.Examples of every possible usage scenario are not given, in fact it's rare I find a manpage that includes an example at all. 3.To understand every little detail, you'd have to read the source code if we're being literal. I'd like to also add that while I can't say a manpage has ever steered me in the wrong direction, I can absolutely say that far more often than not they've steered me in no direction.

Quote:
The net gives always misleading advice, as sites are outdated pretty fast, and folks are proud and blog their "successes" on learning linux.


"The net gives always misleading advice"? To include your advice? :) I kid. Seriously though, a firm 90% of what I've learned to do in linux has come from the internet, so I know that statement to be false. Sites do get outdated, sure, but a lot of the commands and concepts they can be discussing are ...in some cases older than WWW so I'd only worry about that on a case-by-case basis. Folks blogging on their successes quite seriously got me the farthest of all resources available by a WIDE margin. They tend to give multiple examples, explanations of why they found certain things to work, and what might be different about your situation if you're following along at home. Every so often I'll find a video tutorial, too. However, of course there are ones that are wrong and it's near impossible sometimes to tell which is which, especially when you're learning something new. I dealt with this for many years and it was very frustrating to be sure, but eventually, as the internet aged, linux got more popular and I picked up more tricks, I found better answers to my questions. At the end of the day though, if every man page had been written with crystal clarity first and foremost in mind so that even those who were unfamiliar with the layout of unix could pick things up as they went, none of the other resources would have been as needed by so many who all clearly got online and either wrote or sought different explanations. I know I'm not alone in this, I feel like the fact so much educational, walk through, step-by-step, tutorial-driven content exists online is proof enough people need better explanations and better answers.


Top
 Profile  
 PostPosted: Tue Oct 11, 2016 5:53 pm   

Joined: Mon Oct 20, 2014 9:53 am
Posts: 574
Because each beginner post proudly his poor findings folks still use uuoc statements. (google for "useless use of cat award")

To expect each and every manpage having examples for each and every use case and explaning all concepts is somehow dumb.
It gives precise and complete information on how to use the commands.
You have to learn typing on your own.

That's why i wrote "learn to read em".

Nothing left to say.
Take it or leave it.


Top
 Profile  
 PostPosted: Wed Oct 12, 2016 8:15 am   

Joined: Sat Oct 08, 2016 3:25 pm
Posts: 10
Quote:
Because each beginner post proudly his poor findings folks still use uuoc statements. (google for "useless use of cat award")

I know what you mean, and I've seen some...but I'd point out 'cat' is important to know how to use...so to a degree even that's valuable. Are you seriously trying to discredit the efforts of thousands to educate each other more effectively?

Quote:
To expect each and every manpage having examples for each and every use case and explaning all concepts is somehow dumb.

Somehow dumb? You don't have a reason...then? Compelling. You yourself said they explain every little detail, but that's false, and now you say it's dumb that I ask for them to be truly complete. Reconsider.

Quote:
It gives precise and complete information on how to use the commands.

I notice you breezed right over "man term". I disagree with you for the reasons I've given previously.

Quote:
You have to learn typing on your own.

I never mentioned typing. I don't think it's unreasonable to ask for clarity, but the problem, as always, is that people who figure this stuff out forget what it's like not to know it. Then it somehow becomes really easy to turn around and begrudge people their lack of familiarity. That's crap.

Quote:
That's why i wrote "learn to read em".

Yes. There could be some value in learning to unravel the language commonly used in manpages. I think it would be more valuable if they were more clearly written and could then reach a wider audience, be more helpful, etc. I don't know why anyone would oppose that unless you're actually trying to hoard information.

Quote:
Nothing left to say. Take it or leave it.

I leave this. I'll continue to use every resource I have at my disposal, but I think I'm within my rights to want a higher quality of information to be available to everyone.


Top
 Profile  
 PostPosted: Wed Oct 12, 2016 8:31 am   

Joined: Mon Oct 20, 2014 9:53 am
Posts: 574
You want a manpage educating the reader from the beginner to the expert including examples for each and every use case.
This can't be done. And was never meant to be this way.
They are concise and complete information on how to use the command in question.
You don't expect a manual of your new car, to explain all the nifty bits of engine development.
Why then do you expect this from manpages?
Reconsider your alien expectations.

And yes, estimated 80% of blogs on linux teaching bad usage.
And no, use em all, if you like to.
I'm aware that most tuts out here are crab, so i prefer to read manpages.
I'm better off. Obviously.

And i read man term; man terminfo; man tput
To understand how a console works and what a terminal is, you should start with man tput and alike.
If you finally make it up to realize what's it all about, then you will understand man term as well.


Top
 Profile  
 PostPosted: Wed Oct 12, 2016 9:50 am   

Joined: Sat Oct 08, 2016 3:25 pm
Posts: 10
Now we're getting somewhere.
I expect man pages to be a manual. I don't think that's too alien.
A quick google shows the definition on manual, so it's not just me:

"a book of instructions, especially for operating a machine or learning a subject; a handbook."

My arguments hinge on many (not all) man pages not meeting this criteria.

So, if my expectation that a 'manpage' that doesn't meet the definition of 'manual' is unrealistic, perhaps they should be called "sometimes-helpful-in-niche-cases pages"

Quote:
And yes, estimated 80% of blogs on linux teaching bad usage.

I'd love love love to see hard proof of this. A link to an article, a reference book, anything.

Quote:
And no, use em all, if you like to.
I'm aware that most tuts out here are crab, so i prefer to read manpages.
I'm better off. Obviously.


I guess you are. It sounds lovely.

Quote:
And i read man term; man terminfo; man tput
To understand how a console works and what a terminal is, you should start with man tput and alike.
If you finally make it up to realize what's it all about, then you will understand man term as well.


"What it's all about" sounds like we're looking for the meaning of christmas or some other ethereal thing. I'm looking for manuals. A text may either meet the definition of a manual or not.

My boss, who has a PhD in computational chemistry and has been using unix since the 80s agrees that the 'man term' page is at *best* a reference pamphlet that's only useful in the context of other man pages and all together they're only useful if you have outside information on what task you're performing. REF: he worked on VAX machines where 'term' was of great importance.

So, when you talk about understanding what it's all about, my current understanding is that 'man term' and several others do not meet the criteria for a manual. My understanding is people had a chance to make allllllll of this much easier and they didn't take it. It's not my fault, it's not your fault, it's just a fact of comparing what something is against what it's meant to be.

You're happy with how things are the way they are, you've got what you want I guess. What about people who don't speak english? How many manpages do you think are only in english? Should everyone be forced to learn english to keep up with the documentation, or wouldn't it be better if someone out there translated it? That's what I'm talking about. Putting in the work to make things better for everyone sounds like a good thing to me.

There's the reality of the situation (which sucks, in my estimation) and there's the idea of what could be better.

I see you're starting to think that I think man pages should teach pre-K through 12th grade, typing and Comp Sci 101. That's not what I'm saying. I think man pages should encompass what it means to be a manual. Nothing more, nothing less. If I write something about....let's keep it technical, an AMD cpu, and I write in there all about the memory registers of the chip, and I discuss the lithography and the cores and the voltages - that's all good to know, but it's not a manual. A manual would explain how it could be used, and provide a context for the reader, what it's for, why it's there, etc.

Let me give another example. This, sir, this is a manual:
https://www.liftmaster.com/catalogresou ... 4a3044.pdf

It provides a context for the reader (the opener gets installed a certain way with certain tools, in a certain place)
It shows how the placement matters and how it connects to the rest of the system.
It provides warnings and figures.
It shows a method for installing the device to completion so it can be used safely and reliably.

This is a good manual. It meets the definition of a manual and then some.

We're beating a dead horse at this point. If you want to remain the #1 fan of manpages, that's cool. I'm not here to convince you to change your mind, I only wanted to demonstrate that I've got a grocery list of reasons behind my stance on this and that you could at least process those reasons. If you don't want to, I guess that's up to you.


Top
 Profile  
 PostPosted: Wed Oct 12, 2016 10:47 am   

Joined: Mon Oct 20, 2014 9:53 am
Posts: 574
Take it or leave it:
man term IS a reference. It shows up therefor in chapter 5 (file formats) and chapter 7 (makros and definitions).
Read man man and even you'll learn how manpages are to handle.

If you insist to find an explanation of what a terminal is, then book some courses.
Manpages ARE NOT intended to teach this.
You have to LEARN usage of manpages in the forehand.
Read man man
instead relying again on some dumb web queries.

I'm not going to prove you dumb tutorials by link.
I think you already have read enough of them.

To insist that the usage of the word "man(ual)" has to follow your ideas or manuals for reparing a broken engine of your model T is somewhat stupid. And really noone cares about.
I hereby let you know, that words are to be understood within their context.

This is my last post in this thread.


Top
 Profile  
 PostPosted: Wed Oct 12, 2016 11:33 am   

Joined: Sat Oct 08, 2016 3:25 pm
Posts: 10
Quote:
Take it or leave it:
man term IS a reference. It shows up therefor in chapter 5 (file formats) and chapter 7 (makros and definitions).
Read man man and even you'll learn how manpages are to handle.

Reference != Manual
If it's /only/ a reference, that makes it closer to what it should be. That makes me wonder why we have man 'whatever' & info 'whatever' & help 'whatever' if man pulls up both references and manuals. We've got the structure, it seems like folks just aren't using it. Based on this and what you've just said, i'd say man 'term' shouldn't be a manpage at all, it may be better suited to something else.

Quote:
If you insist to find an explanation of what a terminal is, then book some courses.

I don't really care what 'term' is right at this moment, it was just an example of a poor manual, which it continues to be, since it's meant to be a reference.

Quote:
Manpages ARE NOT intended to teach this.

This = ...everything? I covered that. They should do what a manual does, unless you willingly choose to reject the definition of the word....and it seems like you do, which is willfully ignorant.

Quote:
You have to LEARN usage of manpages in the forehand.

Which is fine. I'm not so worried about HOW they're used so much as what level of clarity they provide.

Quote:
Read man man

I did, I used it as an example in a previous post. It's a fine example of what a good man page should be.

Quote:
instead relying again on some dumb web queries.

What dumb web queries? Are you seriously against people using the web to learn things? Why are you here? I see your name as the final post in a lot of questions asked on this forum which implies you're offering advice to people on the web. I'll let the irony sink in.

Quote:
I'm not going to prove you dumb tutorials by link.

prove me..dumb..tutorials? What? I linked you to a good example of a good manual, not a tutorial.

Quote:
I think you already have read enough of them.

Cute. You think my ability to search the web and dig up relevant information is negatively effecting me somehow. So far, buddy, one of us has formed an argument on reasons and facts, and the other one of us has rejected definitions and given up on the exchange of ideas.

Quote:
To insist that the usage of the word "man(ual)" has to follow your ideas or manuals for reparing a broken engine of your model T is somewhat stupid. And really noone cares about.
I hereby let you know, that words are to be understood within their context.


It's not MY usage of the word manual. It's THE definition. It's what the word means - Full stop. Where on earth did you get broken engine model T from? No one cares about well written manuals...you know, except for all the people that do. Technical writing is a highly sought after skill and companies depend on it to release real documentation for the things they do. They need this internally and externally as to make sure ideas get across clearly because they can't afford downtime or mistakes. If you really think no one cares, think about that the next time you crack open a book on a complicated subject, assuming you ever do. Or....believe what you want I guess.

Quote:
This is my last post in this thread.

If you insist.


Last edited by VolumetricSteve on Wed Oct 12, 2016 1:47 pm, edited 1 time in total.

Top
 Profile  
 PostPosted: Wed Oct 12, 2016 12:07 pm   

Joined: Mon Mar 02, 2009 3:03 am
Posts: 643
Quote:
I think I'm within my rights to want a higher quality
« don't dream it, be it »


Top
 Profile  
 PostPosted: Wed Oct 12, 2016 1:43 pm   

Joined: Sat Oct 08, 2016 3:25 pm
Posts: 10
Right on. As much as I'd love to re-write every single command page that seems definition-challenged, I'm just one guy.
Plus...I don't think I'd even be allowed to commit permanent changes to the man pages of all these arcane things. They aren't mine to change.
Among the points I tried to make above, there ARE good resources out there that explain some of these things in pretty good clarity, so in that way some of the work has been done.
I get the feeling if I tried to submit changes to manpages, I'd have to do so for each author for each application, and I suspect I'd be met with similar and equally reasonable resistance as I was met with above.

I guess there's an underhanded way to do it where I could rewrite things, and distribute my own manpages as a totally separate package, but people would have to go out of their way for it which seems unlikely at best. That feels like that's violate some agreement somewhere but I'm not sure, either way it'd be impractical.

The most practical approach I take already is when someone on a forum asks a question, the last thing I do is quote documentation at them. I assume they've tried that and come to the forum either because they didn't understand it or they understood it and it didn't answer their question. I try to understand their problem and step through it with them UNLESS their question is something that is answered verbatim in a manpage, or some other documentation(links, forums, books, whatever). Such as: "how do I list everything in a directory?" then I'd show them "ls -a would do that, ls's flags are covered in the ls manpage" So in the event the EXACT question is covered right there, that's a good use case for the manpage since...it's there. In any other case that requires some degree of interpretation like "how does a certain command work" could involve more discussion since it's more broad question than what a manpage might provide.


Top
 Profile  
 PostPosted: Wed Nov 02, 2016 11:25 pm   
Site Admin
User avatar

Joined: Sun May 15, 2005 9:36 pm
Posts: 693
Location: Des Moines, Iowa
I'd agree that for newbies, man pages can be, .... less than friendly. However, as you stated, just being "slightly" more enlightened, and you won't find them daunting at all. Don't give up, it gets easier. Your scripts don't have to be "perfect", or conform to "some standard" to be useful. That comes with experience and time. No one writes perfect code when starting out, and everyone has the "growing pains" when starting as well. If the man pages are a bit hard to digest (and I get that), try a book on shell scripting. There are SEVERAL great ones out there.

This is a pretty decent one.
Image
https://www.amazon.com/gp/product/0596009658


Top
 Profile WWW  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 8 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
cron


BashScripts | Promote Your Page Too
Powered by phpBB © 2011 phpBB Group
© 2003 - 2011 USA LINUX USERS GROUP