Re: bash should consult .config/bash/...
On Sunday, December 10, 2023, Koichi Murase wrote: > > In that case, a question would be what would be the standard way to > specify the Bash-specific variable, > There doesn't have to be a standard way; I'd set it in ~/.profile, you'd set it wherever is convenient on your setup.
Re: bash should consult .config/bash/...
Date:Sun, 10 Dec 2023 18:59:22 +0300
From:=?UTF-8?B?T8SfdXo=?=
Message-ID:
| There doesn't have to be a standard way; I'd set it in ~/.profile, you'd
| set it wherever is convenient on your setup.
The point is that the people who want this don't want to have a ~/.profile
(or generally almost *any* "." files in $HOME). So what you have as
~/.profile would instead be ~/.config/bash/profile (or something similar).
I've been using a DOTFILE env var for years for this purpose, and my
~/.bashrc file (for example) is a one-liner which contains:
test -r "${DOTFILE}/bash/rc" && . "${DOTFILE}/bash/rc"
(approximately). It doesn't serve the purpose of eliminating the . files
from $HOME, but it does make it easier to find all the bash related config
files and more easily grep them to find which one contains something stupid.
It also makes it easier to move the entire config from one system to
another, without also accidentally moving piles of crap in other ~/.*
files that random other applications decided that they just *must* have
for their private storage.
kre
Re: $((expr)) allows the hexadecimal constant "0x"
On 11/30/23 5:18 AM, Martin D Kealey wrote: If there's a bug tracking system beyond "threads in a mailing list", I'd like to know how I can get access to it. https://savannah.gnu.org/support/?group=bash -- ``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/ OpenPGP_signature.asc Description: OpenPGP digital signature
Re: $((expr)) allows the hexadecimal constant "0x"
On 11/30/23 5:18 AM, Martin D Kealey wrote:
When I said:
> This change will break scripts that use $((10#$somevar)) to cope with
> somevar having leading zeroes OR BEING EMPTY.
Chet replied:
this clearly invalid syntax
"Clearly Invalid" is a matter of perspective. To me "no digits at all" is
the MOST logical way to write value zero, being the logical result of
"remove leading zero digits".
OK, this is worth discussion. So you write your hex constant 0 as "0x",
like the subject of this thread suggests? Where do you think that's going
to be valid? Or something like
"" + 7
should be 7? Now, bash does accept this, but no one else does (a
consequence of the bash arithmetic evaluator trying to be extra-friendly).
None of it is valid C arithmetic syntax, which is what we're all supposed
to be using for this. Hell, according to the C standard, anything with a
leading zero is an octal constant by definition (unless after a
hexadecimal-prefix). There is no decimal constant `0'.
In the end, this strategy of removing leading zeros breaks down as
identical to the accumulator strategy of arithmetic constant evaluation:
tot = (tot * base) + digit_value. There's no separate "remove leading
zeroes" step. But there's no valid C constant that has zero digits
anyway, so this is all academic.
(I may be sufficiently atypical that nobody
on this list agrees with me, but I'm definitely not unique globally.)
Sure, it's a big world. But is it a popular enough view that it would do
more than confuse people?
That change introduced an inconsistency into Bash:
X= ; ((X == 0)) # true
X= ; ((10#$X == 0)) # was true, now broken
These are not the same. If you want to make the examples the same in terms
of what the arithmetic evaluator sees, write
(( $X == 0 ))
since word expansion happens before the `((' compound command runs.
Chet said:
You might be interested in the discussion:
https://lists.gnu.org/archive/html/bug-bash/2018-07/msg00015.html
https://lists.gnu.org/archive/html/bug-bash/2019-06/msg00039.html
I read that and wept.
Just because someone didn't understand the difference between a single
token and an entire arithmetic expression doesn't mean "change the
definition of a token" was the right response.
In both examples, the OP didn't understand that `-' is an operator. It's
not part of an integer constant. You're talking about the definition of an
integer constant, not that the `definition of a token' got changed (unless,
of course, you're talking about the specific integer constant token type).
Even if this seemed to be clearly the reasonable response, why was there no
clear & separate solicitation of feedback for "we propose to invalidate
"10#" without any following digits"?
It came up as a bug report in
https://lists.gnu.org/archive/html/bug-bash/2019-06/msg00042.html
(part of the followup discussion after the second linked thread above)
and the consensus among those who participated was that it was a good
thing to prevent base# without any digits from silently being treated
as 0. Do you think there would have been more discussion in different
circumstances? Would you have participated, considering there's no sign
of you on the bug-bash list between 2016 and 2020?
>> However, a somewhat similar situation with hex prefix,
>> 0xDIGITS, still allows just "0x" as a valid zero constant.
>>
>> Not sure whether this should be considered a bug,
>> and whether it's worth fixing - just letting you know.
>>
>
> No, definitely not. It's established behaviour, and should not be
removed
> without an explicit shopt.
It's clearly a bug -- it's an invalid C constant. I suppose we can call
it an extension.
"Clearly a bug" is a matter of opinion,
Come on. Bash (and POSIX) define arithmetic in terms of how C does it,
and that is an invalid C integer constant. It's not even shell-specific
syntax like base#number; it's something that C defines. Is it worth it
trying to be helpful, or is it better to follow the standard you say you
do?
--
``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/
OpenPGP_signature.asc
Description: OpenPGP digital signature
Sv: TAB completion bug
Fra: Chet Ramey >On 12/5/23 6:46 PM, Ole Tange via Bug reports for the GNU Bourne Again SHell wrote: >> For the (admitedly weirdly named) dirs below TAB completion does not >> work correctly. >Thanks for the report. Where did you encounter these directory names? Test purposes. GNU Parallel uses $TMPDIR, and had a bug where \n in $TMPDIR would cause it to fail. To guard against bugs like that all testing is now done with $TMPDIR containing \n, `cmd` and other special shell chars. /Ole
Make reverse-i-search failure joltingly clear
Type ^R and some string, At the point while we are typing that the search fails, all that happens is the word "failed" gets added at front, (reverse-i-search)`nni': set jida^Ci.org/geo/house_numbering/grids/us/il/lake/lake_county/ (failed reverse-i-search)`nnii': set jida^Ci.org/geo/house_numbering/grids/us/il/lake/lake_county/ (The ^Cs are where I quit in order to make this "screenshot".) The average Joe, if looking up at his screen, will mostly just notice the line getting longer and longer for each character he types, no matter if it started failing many characters ago. Hmmm, how does emacs handle such situations? Well when the first failed character is entered there is a flash. Then every additional useless character entered gets a red background. Anyway Bash could be more aggressive to wake the user up to the fact that "He is hiking up the wrong trail. Sending money to candidates who already quit the race and shut their accounts." -- typing for no reason. Let's see, it could flash/beep on each useless character. And or refuse to echo them etc. Anyway, after such improvements the average user, instead of typing five or six useless characters before realizing failure has already occurred, would type just one or two! One might say that negative doggy training (beeps, red characters (if color turned on), frozen line), wouldn't be needed if the user would just please be aware of the word "failed" at the start of the line. Well that word isn't even in uppercase.
Re: Make reverse-i-search failure joltingly clear
At 2023-12-11T15:09:26+0800, Dan Jacobson wrote: > Type ^R and some string, > At the point while we are typing that the search fails, all that > happens is the word "failed" gets added at front, Not for me. I also get a visual bell for each character I add to the pattern once the match fails. You might make sure the (visual/audible) bell in your terminal emulator is enabled. Regards, Branden signature.asc Description: PGP signature
Re: Make reverse-i-search failure joltingly clear
On Mon, Dec 11, 2023 at 1:09 AM Dan Jacobson wrote: > Type ^R and some string, > At the point while we are typing that the search fails, all that > happens is the word "failed" gets added at front, > > (reverse-i-search)`nni': set > jida^Ci.org/geo/house_numbering/grids/us/il/lake/lake_county/ > (failed reverse-i-search)`nnii': set > jida^Ci.org/geo/house_numbering/grids/us/il/lake/lake_county/ > > (The ^Cs are where I quit in order to make this "screenshot".) > > The average Joe, if looking up at his screen, will mostly just notice > the line getting longer and longer for each character he types, no > matter if it started failing many characters ago. > > Hmmm, how does emacs handle such situations? Well when the first > failed character is entered there is a flash. Then every additional > useless character entered gets a red background. > > Anyway Bash could be more aggressive to wake the user up to the fact > that "He is hiking up the wrong trail. Sending money to candidates who > already quit the race and shut their accounts." -- typing for no > reason. > > Let's see, it could flash/beep on each useless character. And or > refuse to echo them etc. > > Anyway, after such improvements the average user, instead of typing > five or six useless characters before realizing failure has already > occurred, would type just one or two! > > One might say that negative doggy training (beeps, red characters (if > color turned on), frozen line), wouldn't be needed if the user would > just please be aware of the word "failed" at the start of the line. > > Well that word isn't even in uppercase. > > Bash beeps on each failed character for me. And I can set my terminal to flash (visual bell) instead of or perhaps in addition to beeping when a bell character (^G) is transmitted. -- Visit serverfault.com to get your system administration questions answered.
