Quote:
Originally Posted by
Corona688
The output of all of those looks readable, is the thing. Neither too many lines, nor too wide, to be visible. Not 100% consistent when you give it different options and configurations, but that's kind of the point -- it's a command that's designed to automatically format itself to be readable, and so far you haven't managed to make it not be so. What, exactly, is actually wrong?
Yes, it's all readable and usable. Yes, the different options produce different results and that is to be expected. As I've stated earlier in the thread, what I'm after is some real understanding of exactly
what the interactions are and
how they work. I'm trying to learn something usable from this experience. I'm not the kind of guy who simply accepts "here, use this code, it works in this case". I've always been driven to peel back the layers and understand why it works the way it does so that I can apply that knowledge appropriately to other situations.
So, I don't understand why
- with the default setting of COLUMNS, the list with a short literal ('None') presented as a single column, but with a longer literal ('None of the above') it presented in three columns.
- setting the value of COLUMNS to 20 caused the previous 3 column list to be presented as one column.
- echoing $COLUMNS from the command prompt produced a value (80), but echoing it from within the shell script called from the same command prompt resulted in what appears to be nulls. I would have expected (and all of my previous experience confirms) that the shell script would have inherited the entire environment from the calling process. So I would expect the default value of COLUMNS within the script to be the same as the value at the command prompt that called the script.