Re: Feature request: Enable possibility of colored stderr output
Hello. Thanks everyone for explaining that Bash can't have effect on other processes stderr. Chet, yes I certainly think it would be a good feature enabling more colorization in Bash's own output. About the other types of information you pointed out I think that's a good idea to consider them too. Just to be clear: I am not giving any opinion on whether this feature should be enabled by default or not, just that the possibility exist for the user to choose to use or not. As I briefly mentioned in my first email, using colorization to differentiate different types of messages could improve readability of the terminal and be helpful for the user. I hope it seems fairly apparent to most people that if you have a body of text, if certain parts of the text, like errors and warnings, are in a different color than the "normal" text, that would result in the text being more readable as opposed to if all the text were just in a single color and no other methods were used to distinguish. I have not researched the topic more in depth but I think it would be easy to do some searching online and finding various results, like studies on methods for improving the presentation of information. Here is just something I found by a quick search: https://blog.prototypr.io/effective-color-coding-bb83d698acb2?gi=dc87d4a4b1ae "This research finds that color coding has an important effect on improving information acquisition and memory. People have a limited capacity for processing information and visual stimuli. Color helps us categorize the instructional stimuli we are presented with." Best Regards Alex On 9/14/20 3:52 PM, Chet Ramey wrote: On 9/13/20 5:59 AM, A M wrote: Hello, I would like to submit a feature request/suggestion on Bash. (I was told submitting to this mailing list was the right way to do it.) Feature request: Enable possibility of colored stderr output. Let's separate the two cases: bash coloring its own output to stderr, which is usually warnings and errors, and output to stderr by processes bash runs. We can discard the latter case right away -- bash doesn't, and shouldn't, have any effect on another process's stderr other than redirecting it. That's something that should be left to the other process. If you really want it, you can do things outside of bash itself to achieve it. The first case is different: would there be any advantage to having bash color its own error messages? And how about other information that gets printed to stderr, like warnings or job status messages?
Re: Do a readline function execution inside bash
2020-09-15 10:59 Budi : > simply run a readline function among lines codes of bash script such > a menu-complete, or previous-history repeated thrice, or etc What is not clear is not how you call the readline function, but what kind of ``script'' do you assume? a. If it is the normal executable script which can be used as `./script.sh', the question doesn't make sense because there is no command line and no readline. Readline is only enabled in an interactive session of Bash. So one can guess that you are either asking how to enable the readline in a script, or talking about some other type of scripts that you haven't explained. b. If you want to enable readline and accept user inputs, you can use `read -e' as Greg wrote. If you want to control the detailed behavior of `read -e' (i.e., how it behaves for each keystroke) by Bash scripts, the answer is it's impossible. c. Maybe you are thinking of sourcing a script in an interactive shell, such as $ source script.sh In this case, it is still unclear what you want to do because the readline is inactive on the command execution. There is no prompt or command line when the user command is executed. d. Another possibility is that you are talking about the shell commands executed in `bind -x '"keyseq":unix-command''. In this case, it is impossible to invoke a readline function directly from the shell commands. But some limited class of mixed operations can be implemented by combining the `bind '"...":"..."'` macro. e. Or maybe you are thinking of a completely different type of ``script''? -- Koichi
Re: Do a readline function execution inside bash
> On Sep 14, 2020, at 9:59 PM, Budi wrote: > > simply run a readline function among lines codes of bash script such a > menu-complete, or previous-history repeated thrice, or etc That doesn't really answer Greg's question. What larger task are you trying to accomplish by invoking readline functions in this way? vq P.S. Again, this is not really appropriate for bug-bash@gnu.org. Please send these sorts of questions to help-b...@gnu.org instead.
Re: Do a readline function execution inside bash
simply run a readline function among lines codes of bash script such a menu-complete, or previous-history repeated thrice, or etc On 9/15/20, Budi wrote: > simply run a readline function among lines codes of bash script such a > menu-complete, or menu-complete repeated thrice, or etc etc > > On 9/14/20, Greg Wooledge wrote: >> On Mon, Sep 14, 2020 at 10:09:16PM +0700, Budi wrote: >>> How to do a readline function execution inside bash script as mimic to >>> actual key press ? >> >> Please tell us what you're actually trying to do. It makes a huge >> difference. >> >> You said "script", so I guess you don't want to pre-populate the input >> buffer of an interactive shell. That would be one goal, and we could >> tell you how to do that, but if it's not what you want, that would be >> a waste of time. >> >> Perhaps you want to pre-populate the user's response to a prompt written >> by the script, for a read command. That's pretty easy: you just have to >> tell read to use readline (-e), and then supply an initial response (-i). >> >> read -r -e -i "$LOGNAME" -p "Who are you? " who >> >> If that's not what you want, then we need to know what you *do* want. >> >
Re: Do a readline function execution inside bash
simply run a readline function among lines codes of bash script such a menu-complete, or menu-complete repeated thrice, or etc etc On 9/14/20, Greg Wooledge wrote: > On Mon, Sep 14, 2020 at 10:09:16PM +0700, Budi wrote: >> How to do a readline function execution inside bash script as mimic to >> actual key press ? > > Please tell us what you're actually trying to do. It makes a huge > difference. > > You said "script", so I guess you don't want to pre-populate the input > buffer of an interactive shell. That would be one goal, and we could > tell you how to do that, but if it's not what you want, that would be > a waste of time. > > Perhaps you want to pre-populate the user's response to a prompt written > by the script, for a read command. That's pretty easy: you just have to > tell read to use readline (-e), and then supply an initial response (-i). > > read -r -e -i "$LOGNAME" -p "Who are you? " who > > If that's not what you want, then we need to know what you *do* want. >
Re: Bash-5.1-beta available
Date:Mon, 14 Sep 2020 12:04:02 -0400
From:Chet Ramey
Message-ID: <6377c2e5-b496-8a80-2f86-d70a6f825...@case.edu>
| "However, the double-quote character ( '"' ) [edited, since the HTML on the
| web site is malformed]
So it is, what a mess, the pdf formatted version is fine, so that is just
a conversion error. Wonder if it is fixed yet? If not you should file
an Online Pubs bug about it. I know some similar ones were fixed, but
I don't see any immediate mention of that one (ref bugs 955 & 1060 for
similar issues).
| shall not be treated specially within a here-
| document, except when the double-quote appears within "$()", "``", or
| "${}"."
The first $() is clear, that starts a new quoting context, just thinking
about the 2nd almost makes my head explode, I have no idea what should be
done with that one, or how it can be justified, the ${} case (since it is
in a here doc, is already quoted, and hence the only defined quotes are
after # ## % or %% operators - so that's what it must be referring to).
But this (because it was all created because of limitations in the original
(7th edn) Bourne Shell is all a huge mess.
For a long time I was hoping that by making what happens with quotes inside
a var expansion (the substring forms excepted) unspecified, and hence not
something that applications can rely upon, would mean that eventually (perhaps
way into the future) shells would be able to do things properly, rather than
all follow the original shell because scripts break otherwise(the reason
apparently that Korn switched ksh back from sane) when no-one is relying
upon stuff like
"${var:-"unquoted-text"}"
any more.
I have since realised that day can never come, as while we may eventually
see an end to that kind of nonsense, we will never be able to rid ourselves
of
"${var-stuff}"
where scripts are relying on "stuff" being quoted. So we can never make
that go back to being unquoted, which would allow quotes to work properly
in contexts like that. Very sad really.
I'm rambling Never mind.
| The question is how special [insert eye-roll emoji], and what
| rules you follow. It seems like shells follow the double-quoting rules if
| they follow any.
For \ in a here-doc (unquoted end-delim) the double-quoting rules apply.
That much is certain I think. (\n is certainly the 2 chars '\' 'n' and
never a newline (a $'' cannot be embedded in a here doc, just as it cannot
be in a double quoted string), and never just n (not even a quoted n)).
Where a " is special in a here-doc (eg: inside a $() which is an unquestioned
case) there is no question but that a \ makes the " just a char (and the \
goes away when it does that).
The only real question here is just where/when the " is special in the here
doc. Since there is no question that if
"${foo}"
appears in a here doc, and we have had foo=bar previously, then the result
is "bar" and if
\"${foo}\"
appears instead, the result is \"bar\". All shells agree on those.
There's also no question but that if foo='bar"' then
${foo%\"}
in a here doc (or anywhere for that matter) produces "bar", there the
quote is special, as it might have been going to be
${foo%"*"}
where the quotes quote the '*' and make it a literal, not a "match anything").
Since the " is special there, the \ escapes it, and so we get a literal
(quoted, not that it matters) double-quote.
So that just leaves
${foo+"xyz"}
Interpreting those double quote chars as quoting the xyz in a here doc,
when, whatever they do, they definitely don't quote the xyz elswhere if
(to emulate a here doc) this appears in a double quoted string
"${foo+"xyz"}"
whatever those "inner" quotes do (original Bourne shell had ${foo+ quoted,
and the final }, and xyz unquoted), these days almost anything is possible,
except for making xyz quoted (it would be without the inner double quotes).
Anyway, making the quotes when they appear in a here doc become quoting
chars, when they don't when not in a here doc, when in a here doc double
quote chars normally aren't quoting chars, would be simply bizarre.
If POSIX needs even more attention to this, then I guess that's what we
need to do (but we know that as soon as we do that, the result will be
that the meaning will become unspecified...)
kre
Re: Bash-5.1-beta available
On 9/13/20 4:51 PM, Robert Elz wrote:
> | The specific construct is
> |
> | P=A
> | cat < | ${P+\"$P\"}
> | EOF
>
> That should output \"A\"
OK, let's discuss it.
>
> | In this case, the usual proscription on double quotes in here-documents
> | does not apply, since the double quote appears within ${}.
>
> Huh? Where does that come from, at best a " inside a quoted ${} is
> unspecified. But in a here doc, " is simply not a quoting char at all.
"However, the double-quote character ( '"' ) [edited, since the HTML on the
web site is malformed] shall not be treated specially within a here-
document, except when the double-quote appears within "$()", "``", or
"${}"."
https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_07_04
That implies that the double quote *is* treated specially when it appears
within a ${} expansion inside the body of a here-document, so the backslash
quotes it. The question is how special [insert eye-roll emoji], and what
rules you follow. It seems like shells follow the double-quoting rules if
they follow any.
(There's also whether or not the double quotes in the above text are
grammatical or syntactically significant.)
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bash-5.1-beta available
On 9/13/20 2:45 PM, Andreas Schwab wrote: > You have a regression here though: > > cat < \" > EOF Thanks, you're right. I'll take a look. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Do a readline function execution inside bash
On Mon, Sep 14, 2020 at 10:09:16PM +0700, Budi wrote: > How to do a readline function execution inside bash script as mimic to > actual key press ? Please tell us what you're actually trying to do. It makes a huge difference. You said "script", so I guess you don't want to pre-populate the input buffer of an interactive shell. That would be one goal, and we could tell you how to do that, but if it's not what you want, that would be a waste of time. Perhaps you want to pre-populate the user's response to a prompt written by the script, for a read command. That's pretty easy: you just have to tell read to use readline (-e), and then supply an initial response (-i). read -r -e -i "$LOGNAME" -p "Who are you? " who If that's not what you want, then we need to know what you *do* want.
Do a readline function execution inside bash
How to do a readline function execution inside bash script as mimic to actual key press ?
Re: Feature request: Enable possibility of colored stderr output
On 9/13/20 5:59 AM, A M wrote: > Hello, I would like to submit a feature request/suggestion on Bash. (I was > told submitting to this mailing list was the right way to do it.) > > Feature request: Enable possibility of colored stderr output. Let's separate the two cases: bash coloring its own output to stderr, which is usually warnings and errors, and output to stderr by processes bash runs. We can discard the latter case right away -- bash doesn't, and shouldn't, have any effect on another process's stderr other than redirecting it. That's something that should be left to the other process. If you really want it, you can do things outside of bash itself to achieve it. The first case is different: would there be any advantage to having bash color its own error messages? And how about other information that gets printed to stderr, like warnings or job status messages? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Bug in aclocal.m4 / configure ? BASH_STRUCT_WEXITSTATUS_OFFSET
> > Yes, thanks. It's a typo, but has no effect on obtaining the right answer. > On some weird yet-to-be-encountered system, if the exit status were not > available at some offset in the status word, it would result in an infinite > loop. > Indeed, and that's what I observed. Trying to figure out right now whether qemu or glibc (both ~ git master) are at fault... Thanks! -Andreas -- Andreas K. Hüttel dilfri...@gentoo.org Gentoo Linux developer (council, qa, toolchain, base-system, perl, libreoffice) signature.asc Description: This is a digitally signed message part.
Re: Bug in aclocal.m4 / configure ? BASH_STRUCT_WEXITSTATUS_OFFSET
On 9/13/20 6:17 PM, Andreas K. Hüttel wrote: > Hi, > > in aclocal.m4 (and thus also configure), the test for > BASH_STRUCT_WEXITSTATUS_OFFSET contains > > /* crack s */ > for (i = 0; i < (sizeof(s) - 8); i++) > > Shouldnt this be > > /* crack s */ > for (i = 0; i < (sizeof(s) * 8); i++) > > (* instead of -), see attached trivial patch? The minus sign makes no sense > at > all since even on x86-64 sizeof(int)=4 ... Yes, thanks. It's a typo, but has no effect on obtaining the right answer. On some weird yet-to-be-encountered system, if the exit status were not available at some offset in the status word, it would result in an infinite loop. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: Feature request: Enable possibility of colored stderr output
On Sun, Sep 13, 2020 at 11:59:45AM +0200, A M wrote: > Feature request: Enable possibility of colored stderr output. Not possible. Output does not "pass through" bash on the way to the terminal. Bash is like a plumber or a switchboard operator. Bash just screws all the pipes together, or plugs the wires into the holes, and then stands back and lets the water flow, or the people talk to each other. When you run a command like foo 2>&1 | bar bash sets up a pipe, and then forks two subshells, and connects the stdout of the "left" side to the pipe's input hole, and connects the stdin of the "right" side to the pipe's output hole. Then, on the "left" side, bash closes stderr and then reopens it as a duplicate of stdout. Finally, each child bash executes its command, while the parent waits for them to be finished. The handling of stdout or stderr is done by foo and by bar. It's outside of bash's control. > Below are links to some discussions/articles on stderr colorization, I > include them as examples of the interest/demand for this functionality: > > https://stackoverflow.com/questions/6841143/how-to-set-font-color-for-stdout-and-stderr If you like any of the hacks presented in this discussion, go ahead and use them. Note that they *are* hacks, truly, and they only give you something that could be called "close enough" in certain cases. I did not open your other links. I'm guessing they're more of the same.
