Re: hash not restored after running command -p
On Mon, Nov 01, 2021 at 09:09:19AM +0300, Oğuz wrote: > On Sun, Oct 31, 2021 at 10:26 PM Mike Jonkmans wrote: > > POSIX is also silent on this. > > I think ``Once a utility has been searched for and found [...], an > implementation may remember its location and need not search for the > utility again unless the PATH variable has been the subject of an > assignment'' pretty much covers it. This wording does not cover it wholly, in my opinion. Because when the utility's hashed path is not in $PATH, then the utility should not have been searched for at all. It should not be found, even if it is remembered. The way it works now, is that the hashed keys are made into aliases. These hash-aliases circumvent PATH search. It is not specified by POSIX and I think it is an unwanted trap. > `command -p command_name' doesn't > alter `PATH', and the shell may or may not remember the location of > `command_name' obtained using the default value for `PATH'. Implicitly this sets PATH. So it should not mess with the outcome of later PATH searches. > > Note that it is not always the same person writing the code. > > The script might be written/changed by someone unaware of the side effects. > > I assume script writers would know about PATH and alias effects, > > less so about 'hash' and even fewer people would know about 'command -p'. > > Yeah, it'd be better if the feature in question were documented. Best would be to only return hash matches that are in PATH. Second best would be to let 'command -p' not mess with the hash. Third best is document current behaviour. -- Regards, Mike Jonkmans
Re: hash not restored after running command -p
I agree, this looks to be broken in bash - "command -p cmd" is (logically)
oldpath=$PATH
PATH=/standard:/system:/path
cmd
PATH=$oldpath
and should act (as if) that way.
What's more, from all the shells I have tested, bash is the only one
to behave like this, every other shell (including zsh), when set up so
that "ls" is not found in PATH (typically by removing /bin from PATH -
perhaps different on some systems, or with more removed - and regardless
of whatever else is left there) does
ksh93{2} $ ls
/usr/pkg/bin/ksh93: ls: not found [No such file or directory]
ksh93{2} $ command -p ls; ls
[list of files in "." from "command -p ls" deleted here]
/usr/pkg/bin/ksh93: ls: not found [No such file or directory]
ksh93{2} $
which is how it should be - the hash table is intended to speed PATH
searches for commonly used commands, nothing should be found there
which wouldn't be found from a PATH search - with the sole exception
that the shell isn't required to check that the filesystem hasn't
changed out from under it (eg: putting a new "ls" in some directory
mentioned in PATH before /bin - if that happens, the user needs to
inform the shell, using "hash -r" (or possibly, an assignment to PATH).
This is also somewhat inconsistent in bash, if one does, with the
same setup as above, but without having done the "command -p ls",
then:
PATH=/bin ls
the ls command works, "ls" is found by the PATH search, but is not added
to the hash table (which is correct). A subsequent "ls" correctly
says:
bash: ls: command not found
If it is to be considered correct to add the entry in the command -p
case, why would it not be correct in this case as well? The only
difference is where the (temporary) modified PATH comes from.
kre
ps: should this be discussed for clarification in POSIX, I have no doubt
which way the result would go.
Re: hash not restored after running command -p
On Mon, Nov 1, 2021 at 10:58 AM Mike Jonkmans wrote: > This wording does not cover it wholly, in my opinion. > Because when the utility's hashed path is not in $PATH, > then the utility should not have been searched for at all. > It should not be found, even if it is remembered. Is the rest of this paragraph your opinion too or did I miss where the standard/bash manual says anything to this effect? > > The way it works now, is that the hashed keys are made into aliases. > These hash-aliases circumvent PATH search. > It is not specified by POSIX and I think it is an unwanted trap. POSIX does not mandate that the directory portion of the pathname used for executing a command be found in the current value of `PATH' either. Perhaps this calls for an clarification request. > Implicitly this sets PATH. > So it should not mess with the outcome of later PATH searches. Again, nowhere it is said that `command -p' involves modifying `PATH'.
Re: hash not restored after running command -p
On Mon, Nov 01, 2021 at 12:21:41PM +0300, Oğuz wrote: > On Mon, Nov 1, 2021 at 10:58 AM Mike Jonkmans wrote: > > This wording does not cover it wholly, in my opinion. > > Because when the utility's hashed path is not in $PATH, > > then the utility should not have been searched for at all. > > It should not be found, even if it is remembered. > > Is the rest of this paragraph your opinion too or did I miss where the > standard/bash manual says anything to this effect? Everything is opinion, in my opinion. ;) I think that you miss that remembering does not equal using. > > The way it works now, is that the hashed keys are made into aliases. > > These hash-aliases circumvent PATH search. > > It is not specified by POSIX and I think it is an unwanted trap. > > POSIX does not mandate that the directory portion of the pathname used > for executing a command be found in the current value of `PATH' > either. Perhaps this calls for an clarification request. Surely. > > Implicitly this sets PATH. > > So it should not mess with the outcome of later PATH searches. > > Again, nowhere it is said that `command -p' involves modifying `PATH'. Temporarily using a default value of PATH is akin to modifying it. -- Regards, Mike Jonkmans
Re: hash not restored after running command -p
On Mon, Nov 1, 2021 at 1:33 PM Mike Jonkmans wrote: > Temporarily using a default value of PATH is akin to modifying it. But they are not the same thing, and you know this. The standard is neither on your side nor mine.
Re: hash not restored after running command -p
On 11/1/21 4:42 AM, Robert Elz wrote: > I agree, this looks to be broken in bash - "command -p cmd" is (logically) > > oldpath=$PATH > PATH=/standard:/system:/path > cmd > PATH=$oldpath > > and should act (as if) that way. Clearly that's not the case. None of the side effects from assigning to PATH occur. What the OP wants here is for `command -p' not to 1. use the hash table 2. modify the hash table There's nothing in the POSIX description of `command' or `hash' that implies this. Both end up referencing https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01_01 which says, in part, "Once a utility has been searched for and found (either as a result of this specific search or as part of an unspecified shell start-up activity), an implementation may remember its location and need not search for the utility again unless the PATH variable has been the subject of an assignment." which seems at best inconclusive. I can see not using the hash table (otherwise why use `command -p' at all?), but I don't see any support for 2. > > which is how it should be - the hash table is intended to speed PATH > searches for commonly used commands, nothing should be found there > which wouldn't be found from a PATH search - This isn't true in bash, either: `hash -p' exists. > This is also somewhat inconsistent in bash, if one does, with the > same setup as above, but without having done the "command -p ls", > then: > PATH=/bin ls > > the ls command works, "ls" is found by the PATH search, but is not added > to the hash table (which is correct). A subsequent "ls" correctly > says: > bash: ls: command not found > > If it is to be considered correct to add the entry in the command -p > case, why would it not be correct in this case as well? Bash actually used to implement `command -p' that way (`command -p name stuff' was implemented as the equivalent of `PATH=magicpath name stuff'), but it's not what you want: if you do it like that, `name' ends up inheriting the magic value of PATH and I got bug reports about that. So `command -p' has to be magic: it uses a magic internal version of $PATH for lookups, which may come from a call to getconf(3) but doesn't have to, but otherwise behaves exactly as if PATH were set to that value for the purpose of POSIX's command search and execution. You can argue for a change in behavior, which I suppose is what's happening here, but there's little support for it in the standard. -- ``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: hash not restored after running command -p
On Mon, Nov 01, 2021 at 03:42:11PM +0700, Robert Elz wrote: > ... > which is how it should be - the hash table is intended to speed PATH > searches for commonly used commands, nothing should be found there > which wouldn't be found from a PATH search - with the sole exception > that the shell isn't required to check that the filesystem hasn't > changed out from under it (eg: putting a new "ls" in some directory > mentioned in PATH before /bin - if that happens, the user needs to > inform the shell, using "hash -r" (or possibly, an assignment to PATH). Is this 'sole exception' in POSIX? It is what bash currently does. Preferably the whole hash/remembering would be transparent, only an implementation speedup. Another case to think about: # Having /usr/local/bin/ls executable PATH=/usr/local/bin:/bin hash -p /usr/local/bin/ls ls ls # /usr/local/bin/ls rm /usr/local/bin/ls ls How should the last 'ls' be handled? Bash calls /bin/ls - which make the hash transparent. Good. It might also have failed with '/usr/local/bin/ls: No such file or directory'. > This is also somewhat inconsistent in bash, if one does, with the > same setup as above, but without having done the "command -p ls", > then: > PATH=/bin ls > > the ls command works, "ls" is found by the PATH search, but is not added > to the hash table (which is correct). A subsequent "ls" correctly > says: > bash: ls: command not found > > If it is to be considered correct to add the entry in the command -p > case, why would it not be correct in this case as well? The only > difference is where the (temporary) modified PATH comes from. Good point! > ps: should this be discussed for clarification in POSIX, I have no doubt > which way the result would go. There is the issue of 'command -p ...' changing the hash table. Another issue is, the usage of hashed values that are not based in the current PATH. This could be seen as a root cause for the 'command -p ...' problem. Not sure what the POSIX people would say about that. -- Regards, Mike Jonkmans
Re: hash not restored after running command -p
On 10/31/21 12:06 PM, Roger Morris wrote: > Thanks for the reply. Though POSIX may allow this, still the last > line of the following example is rather unexpected behavior > > $ > $ echo echo MY LOCAL tmp/date SCRIPT > tmp/date > $ chmod +x tmp/date > $ > $ PATH=.:/bin > $ date > Sun 31 Oct 2021 11:59:07 AM EDT > $ hash -l > builtin hash -p /bin/date date > $ cd tmp ; date ; cd .. > MY LOCAL tmp/date SCRIPT This seems weird and non-intuitive (why not use the hashed value?), but it's actually a special case that's handled explicitly in the code. If the PATH search that results in a value being put into the hash table finds `.' in the PATH before finding the full path, the hash table remembers that fact and -- as a special case -- checks whether `./name' is an executable file before returning the hashed value on subsequent lookups. It's strange, but everyone seems to do it. > $ > $ PATH=.:/bin > $ command -p date > Sun 31 Oct 2021 11:59:50 AM EDT > $ hash -l > builtin hash -p /bin/date date > $ cd tmp ; date ; cd .. > Sun 31 Oct 2021 12:00:03 PM EDT Once you know the above, this makes sense: `command -p' uses a magic value for PATH, and since that value doesn't include `.' the search doesn't find `.'. This means the full path gets put into the hash table without the flag that says `look at ./date first', and the hashed value gets used. The behavior would, of course, differ if `command -p' didn't do anything with the hash table. 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/
Possible bug with redirect.
I'm very new to linux, so I apologize if I'm reporting a non-bug. I wanted to do this: date > `date +"%Y-%m-%d"`.txt to put the date into a file called 2021-10-16.txt But I accidentally forgot the backticks, so it became date > date +"%Y-%m-%d".txt. And it created a file called "date" and it put the string "2021-10-16.txt" into it. I can understand why the file is called "date", but I got somewhat confused about how the content became the '+"%Y-%m-%d".txt' part. It seems that the date +"%Y-%m-%d".txt is the command part with the one parameter. So we have: date redirect-part +"%Y-%m-%d".txt If I wanted the result that I got, I'd expect the command to be: date +"%Y-%m-%d".txt redirect-part. I went to the https://linuxmint.com community website and joined their IRC chat to see if they had an explanation and they told me it may be a bug, since they couldn't reproduce it for other commands. Regards, Rikke Rendtorff P.S. They also told me I may be one of those users that gets myself into trouble by using commands in ways that no sane person would ever think of. So, at least there's that :)
Re: Possible bug with redirect.
On Mon, Nov 01, 2021 at 04:23:32PM +0100, Rikke Rendtorff wrote: > I'm very new to linux, so I apologize if I'm reporting a non-bug. > > I wanted to do this: date > `date +"%Y-%m-%d"`.txt to put the date into a > file called 2021-10-16.txt > > But I accidentally forgot the backticks, so it became date > date > +"%Y-%m-%d".txt. And it created a file called "date" and it put the string > "2021-10-16.txt" into it. Before we go any further: backticks are deprecated. Command substitutions in new scripts should use the $( ) syntax instead. > I can understand why the file is called "date", but I got somewhat confused > about how the content became the '+"%Y-%m-%d".txt' part. You ran this command: date +"%Y-%m-%d".txt > date The redirection ( > date ) can appear at any point in a simple command. Traditionally, it's written at the end of the command, but in your case, it appeared in the middle. All I did was move it to the expected location to clarify what you did. So, once the redirection is put aside, you ran the 'date' command with one argument. That argument began with a + sign, so date(1) interprets it as an output format. The %Y and %m and %d are replaced by the values from the system clock, and the two hyphens and the .txt are left intact. The resulting output was 2021-10-16.txt as you saw in the file.
some unknown bug, says : command not found
i use a bootstrap thingy that i source via .bashrc and .profile
i have a shell open it sourced np'ly, but then now i tried reloading via '.
~/.bashrc' but it says on two commands not found
its the xbashlink i dont wish to repost cause no good replies to so, but
the set -x is
it says
cat -- '/root/.xbl-states/510861635 1364'bash: :
command not found
cat -- '/root/.xbl-states/11357320 1020' bash: :
command not found
coming from non -x :
. ~/.bashrc
bash: : command not found
bash: : command not found
so in total, i dunno where those errs come from, the reload alao failed (
no updates, like no cat ran )
set -x goes
set -x ; . ~/.bashrc ; set +x
+ . /root/.bashrc ++ .
/root/xbl5/xbl /root/xbl5e/ps1x
+++ set -mb +++ shopt
-s nullglob extglob dotglob globstar lastpipe expand_aliases
+++ unset ye1
realpath /root/xbl5/xbl +++
me=/root/xbl5/xbl
+++ medir=/root/xbl5 +++
states=/root/.xbl-states
+++
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/root/xbl5/bin:/root/xbl5e/ps1x/bin:/root/xbl5/bin
+++ mein=/root+++
supported='/@(eval[12]|bin|set|shopt|declare|function|alias|pc|runtime)/*'
+++ xblpp=.
+++ [[ ! -d /root/.xbl-states ]] +++ [[ -v
xblpe ]]
+++ for arg in "$medir" "$@" +++ [[ !
-e /root/xbl5 ]]
realpath /root/xbl5 +++
rarg=/root/xbl5
+++ pos=("$rarg"$supported) +++ unset
inroot
+++ [[ -d /root/xbl5/root ]] +++ [[ -d
/root/xbl5/bin ]]
+++
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/root/xbl5/bin:/root/xbl5e/ps1x/bin:/root/xbl5/bin:/root/xbl5/bin
+++ [[ -d
/root/xbl5/state ]]
+++ states2=/root/xbl5/state +++
tt=/root/.xbl-states/files.long.857307326276504740
cksum+
kopi.gawk /root/.xbl-states/files.long.857307326276504740
++ find /root/xbl5/alias/_N_ /root/xbl5/alias/_n_
/root/xbl5/alias/restoreIFS /root/xbl5/alias/saveIFS
/root/xbl5/bin/kopi.gawk /root/xbl5/bin/rmneol /root/xbl5/bin/xbl
/root/xbl5/bin/xbl.bash /root/xbl5/bin/xbl.files.gawk
/root/xbl5/bin/xbl.gawk /root/xbl5/function/+kw /root/xbl5/function/kws
/root/xbl5/function/kwseval /root/xbl5/function/mkPATH
/root/xbl5/function/on /root/xbl5/function/pc /root/xbl5/function/per
/root/xbl5/function/restorevar /root/xbl5/function/saveunsetvar
/root/xbl5/function/savevar /root/xbl5/function/states '(' -name '*.off' -o
-name '*.old' -o -name '*.old.*' -o -name '*.off.*' -o -name '*.sw[a-z]'
')' -prune -o -printf '%Y\0%s\0%m\0%T@\0%f\0%p\0\0'
+++ hash='510861635 1364'
+++ t='/root/.xbl-states/510861635 1364' +++
ttt='/root/.xbl-states/files.long.857307326276504740.510861635 1364'
+++
t2='/root/xbl5/state/510861635 1364'
+++ mv -- /root/.xbl-states/files.long.857307326276504740
'/root/.xbl-states/files.long.857307326276504740.510861635 1364'
+++ '' /dev/fd/63 [[
-s /root/.xbl-states/510861635 1364 ]]
cat -- '/root/.xbl-states/510861635 1364'bash: :
command not found
+++ [[ -v inroot ]] +++ for
arg in "$medir" "$@"
+++ [[ ! -e /root/xbl5e/ps1x ]]
realpath /root/xbl5e/ps1x
true +++
rarg=/root/xbl5e/ps1x
+++ pos=("$rarg"$supported) +++ unset
inroot
+++ [[ -d /root/xbl5e/ps1x/root ]]+++ [[ -d
/root/xbl5e/ps1x/bin ]]
+++
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/root/xbl5/bin:/root/xbl5e/ps1x/bin:/root/xbl5/bin:/root/xbl5/bin:/root/xbl5e/ps1x/bin
+++ [[ -d /root/xbl5e/ps1x/state ]]
+++ states2= +++
tt=/root/.xbl-states/files.long.1358754618657271232
cksum+
kopi.gawk /root/.xbl-states/files.long.1358754618657271232
++ find /root/xbl5e/ps1x/bin/prptrecents2.gawk
/root/xbl5e/ps1x/declare/HISTFILESIZE /root/xbl5e/ps1x/declare/HISTSIZE
/root/xbl5e/ps1x/declare/PROMPT_COMMAND /root/xbl5e/ps1x/declare/PS0
/root/xbl5e/ps1x/declare/PS1 /root/xbl5e/ps1x/eval1/3.declares
/root/xbl5e/ps1x/eval1/5.declare_-x_cols
/root/xbl5e/ps1x/ev
Re: some unknown bug, says : command not found
On Mon, Nov 01, 2021 at 04:53:12PM +0100, Alex fxmbsw7 Ratchev wrote: > coming from non -x : > > . ~/.bashrc > > bash: : command not found > bash: : command not found Because this is you, I can't be sure whether you are correctly pasting the output from your terminal into email, or retyping it with who-knows-what changed. *IF* this is a true paste of the output from a terminal, then it appears you've got an invisible character in the command position. Observe: unicorn:~$ ^A bash: $'\001': command not found You see that there are two colons in the output, and a space after the first colon. In between that first space and the second colon, you see the command that bash is complaining about. If I try to run a non-breaking space as a command, then I see this: unicorn:~$ bash: : command not found You may not be able to see it easily, but there are two non-breaking space characters pasted above, one in each line. The characters between the two colons on the second line are bash's space, and the non-breaking space that I typed. It's very hard to imagine what kind of character you could have typed to produce the output you showed in your email. But my knowledge of the gory entrails of Unicode is pretty limited, so who knows what it could be. Or, you might have simply mis-represented the output. That's my guess. > set -x goes > > set -x ; . ~/.bashrc ; set +x > + . /root/.bashrc ++ . > /root/xbl5/xbl /root/xbl5e/ps1x > +++ set -mb +++ shopt This is mangled beyond recognition. You've got missing newlines, or newlines replaced by a multitude of spaces, or... *sigh*. All I can tell you is: 1) Identify WHICH FILE the error is actually coming from. You've probably got some multi-layer hierarchy of sourced/dotted-in files. The first step will be to figure out *which* one has the problem. Do this by commenting things out, or by dotting in the second-tier files manually, or whatever it takes. 2) Once you know the real file that has the problem, use a hex dumper, or a hex editor, or whatever tools you feel will help you, to find the invisible or unprintable character.
Re: some unknown bug, says : command not found
please give me half a day to study that english gg =) On Mon, Nov 1, 2021, 17:04 Greg Wooledge wrote: > On Mon, Nov 01, 2021 at 04:53:12PM +0100, Alex fxmbsw7 Ratchev wrote: > > coming from non -x : > > > > . ~/.bashrc > > > > bash: : command not found > > bash: : command not found > > Because this is you, I can't be sure whether you are correctly pasting > the output from your terminal into email, or retyping it with > who-knows-what > changed. > > *IF* this is a true paste of the output from a terminal, then it appears > you've got an invisible character in the command position. > > Observe: > > unicorn:~$ ^A > bash: $'\001': command not found > > You see that there are two colons in the output, and a space after the > first colon. In between that first space and the second colon, you see > the command that bash is complaining about. > > If I try to run a non-breaking space as a command, then I see this: > > unicorn:~$ > bash: : command not found > > You may not be able to see it easily, but there are two non-breaking > space characters pasted above, one in each line. The characters between > the two colons on the second line are bash's space, and the non-breaking > space that I typed. > > It's very hard to imagine what kind of character you could have typed > to produce the output you showed in your email. But my knowledge of > the gory entrails of Unicode is pretty limited, so who knows what it > could be. > > Or, you might have simply mis-represented the output. That's my guess. > > > set -x goes > > > > set -x ; . ~/.bashrc ; set +x > > + . /root/.bashrc ++ . > > /root/xbl5/xbl /root/xbl5e/ps1x > > +++ set -mb +++ > shopt > > This is mangled beyond recognition. You've got missing newlines, or > newlines replaced by a multitude of spaces, or... *sigh*. > > All I can tell you is: > > 1) Identify WHICH FILE the error is actually coming from. You've probably >got some multi-layer hierarchy of sourced/dotted-in files. The first >step will be to figure out *which* one has the problem. Do this by >commenting things out, or by dotting in the second-tier files manually, >or whatever it takes. > > 2) Once you know the real file that has the problem, use a hex dumper, or >a hex editor, or whatever tools you feel will help you, to find the >invisible or unprintable character. > >
Re: some unknown bug, says : command not found
how, or what, is a non breaking space to try your command for a cmd not found i identified the file is in the main script sourced got a suggestion for a hexdump cmd ? i know of none with args On Mon, Nov 1, 2021, 17:05 Alex fxmbsw7 Ratchev wrote: > please give me half a day to study that english > > gg =) > > On Mon, Nov 1, 2021, 17:04 Greg Wooledge wrote: > >> On Mon, Nov 01, 2021 at 04:53:12PM +0100, Alex fxmbsw7 Ratchev wrote: >> > coming from non -x : >> > >> > . ~/.bashrc >> > >> > bash: : command not found >> > bash: : command not found >> >> Because this is you, I can't be sure whether you are correctly pasting >> the output from your terminal into email, or retyping it with >> who-knows-what >> changed. >> >> *IF* this is a true paste of the output from a terminal, then it appears >> you've got an invisible character in the command position. >> >> Observe: >> >> unicorn:~$ ^A >> bash: $'\001': command not found >> >> You see that there are two colons in the output, and a space after the >> first colon. In between that first space and the second colon, you see >> the command that bash is complaining about. >> >> If I try to run a non-breaking space as a command, then I see this: >> >> unicorn:~$ >> bash: : command not found >> >> You may not be able to see it easily, but there are two non-breaking >> space characters pasted above, one in each line. The characters between >> the two colons on the second line are bash's space, and the non-breaking >> space that I typed. >> >> It's very hard to imagine what kind of character you could have typed >> to produce the output you showed in your email. But my knowledge of >> the gory entrails of Unicode is pretty limited, so who knows what it >> could be. >> >> Or, you might have simply mis-represented the output. That's my guess. >> >> > set -x goes >> > >> > set -x ; . ~/.bashrc ; set +x >> > + . /root/.bashrc ++ . >> > /root/xbl5/xbl /root/xbl5e/ps1x >> > +++ set -mb +++ >> shopt >> >> This is mangled beyond recognition. You've got missing newlines, or >> newlines replaced by a multitude of spaces, or... *sigh*. >> >> All I can tell you is: >> >> 1) Identify WHICH FILE the error is actually coming from. You've probably >>got some multi-layer hierarchy of sourced/dotted-in files. The first >>step will be to figure out *which* one has the problem. Do this by >>commenting things out, or by dotting in the second-tier files manually, >>or whatever it takes. >> >> 2) Once you know the real file that has the problem, use a hex dumper, or >>a hex editor, or whatever tools you feel will help you, to find the >>invisible or unprintable character. >> >>
Re: some unknown bug, says : command not found
On Mon, Nov 01, 2021 at 05:29:08PM +0100, Alex fxmbsw7 Ratchev wrote: > how, or what, is a non breaking space https://en.wikipedia.org/wiki/Non-breaking_space In HTML it's represented by In Unicode it's code point U+00A0 In UTF-8 it's encoded as 0xc2 0xa0 On my system, with Debian's X Compose defaults, I can type one by pressing Compose-Space-Space. Here's the relevant snippet from /usr/share/X11/locale/en_US.UTF-8/Compose: # Spaces : " " nobreakspace # NO-BREAK SPACE It's one of the first things I look for whenever something is visually screwy (along with Carriage Returns). They commonly creep in when someone pastes content from a Microsoft product, or from a web site (or both). > i identified the file is in the main script sourced > > got a suggestion for a hexdump cmd ? i know of none with args On Debian, you can use hd (which is the same as hexdump -C). Or od -tx1.
Re: some unknown bug, says : command not found
the hd one gives me, i think its the only two cat cases : 0410 0a 6d 76 20 2d 2d 20 22 24 74 74 22 20 22 24 74 |.mv -- "$tt" "$t| 0420 74 74 22 0a 0a 24 78 62 6c 70 70 20 3c 28 0a 20 |tt"..$xblpp <(. | 0430 69 66 20 5b 5b 20 2d 73 20 24 74 20 5d 5d 20 3b |if [[ -s $t ]] ;| 0440 20 74 68 65 6e 0a 20 20 63 61 74 20 2d 2d 20 22 | then. cat -- "| 0450 24 74 22 0a 20 65 6c 69 66 20 5b 5b 20 2d 73 20 |$t". elif [[ -s | 0460 24 74 32 20 5d 5d 20 3b 20 74 68 65 6e 0a 20 20 |$t2 ]] ; then. | 0470 63 61 74 20 2d 2d 20 22 24 74 32 22 0a 20 65 6c |cat -- "$t2". el| 0480 73 65 0a 20 20 6b 6f 70 69 2e 67 61 77 6b 20 22 |se. kopi.gawk i cant really see, i gotta first code me an own hexdump in gawk On Mon, Nov 1, 2021, 17:51 Greg Wooledge wrote: > On Mon, Nov 01, 2021 at 05:29:08PM +0100, Alex fxmbsw7 Ratchev wrote: > > how, or what, is a non breaking space > > https://en.wikipedia.org/wiki/Non-breaking_space > > In HTML it's represented by > > In Unicode it's code point U+00A0 > > In UTF-8 it's encoded as 0xc2 0xa0 > > On my system, with Debian's X Compose defaults, I can type one by > pressing Compose-Space-Space. Here's the relevant snippet from > /usr/share/X11/locale/en_US.UTF-8/Compose: > > # Spaces >: " " nobreakspace # NO-BREAK > SPACE > > It's one of the first things I look for whenever something is visually > screwy (along with Carriage Returns). They commonly creep in when someone > pastes content from a Microsoft product, or from a web site (or both). > > > i identified the file is in the main script sourced > > > > got a suggestion for a hexdump cmd ? i know of none with args > > On Debian, you can use hd (which is the same as hexdump -C). Or od -tx1. > >
Re: hash not restored after running command -p
On 11/1/21 11:26 AM, Chet Ramey wrote: > On 10/31/21 12:06 PM, Roger Morris wrote: >> Thanks for the reply. Though POSIX may allow this, still the last >> line of the following example is rather unexpected behavior >> >> $ >> $ echo echo MY LOCAL tmp/date SCRIPT > tmp/date >> $ chmod +x tmp/date >> $ >> $ PATH=.:/bin >> $ date >> Sun 31 Oct 2021 11:59:07 AM EDT >> $ hash -l >> builtin hash -p /bin/date date >> $ cd tmp ; date ; cd .. >> MY LOCAL tmp/date SCRIPT > > This seems weird and non-intuitive (why not use the hashed value?), but > it's actually a special case that's handled explicitly in the code. If the > PATH search that results in a value being put into the hash table finds `.' > in the PATH before finding the full path, the hash table remembers that > fact and -- as a special case -- checks whether `./name' is an executable > file before returning the hashed value on subsequent lookups. It's strange, > but everyone seems to do it. Before we all pile on here, yes, I understand why we all do it. I still think it's non-intuitive, but you have to behave as if the hash table weren't there at all. -- ``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: some unknown bug, says : command not found
to add the small info, its from phone and wsl, no pure linix anymore but on windows wsl i only vim, no this On Mon, Nov 1, 2021, 18:34 Alex fxmbsw7 Ratchev wrote: > the hd one gives me, i think its the only two cat cases : > > 0410 0a 6d 76 20 2d 2d 20 22 24 74 74 22 20 22 24 74 |.mv -- "$tt" > "$t| > 0420 74 74 22 0a 0a 24 78 62 6c 70 70 20 3c 28 0a 20 |tt"..$xblpp > <(. | > 0430 69 66 20 5b 5b 20 2d 73 20 24 74 20 5d 5d 20 3b |if [[ -s $t > ]] ;| > 0440 20 74 68 65 6e 0a 20 20 63 61 74 20 2d 2d 20 22 | then. cat > -- "| > 0450 24 74 22 0a 20 65 6c 69 66 20 5b 5b 20 2d 73 20 |$t". elif [[ > -s | > 0460 24 74 32 20 5d 5d 20 3b 20 74 68 65 6e 0a 20 20 |$t2 ]] ; > then. | > 0470 63 61 74 20 2d 2d 20 22 24 74 32 22 0a 20 65 6c |cat -- "$t2". > el| > 0480 73 65 0a 20 20 6b 6f 70 69 2e 67 61 77 6b 20 22 |se. kopi.gawk > > i cant really see, i gotta first code me an own hexdump in gawk > > On Mon, Nov 1, 2021, 17:51 Greg Wooledge wrote: > >> On Mon, Nov 01, 2021 at 05:29:08PM +0100, Alex fxmbsw7 Ratchev wrote: >> > how, or what, is a non breaking space >> >> https://en.wikipedia.org/wiki/Non-breaking_space >> >> In HTML it's represented by >> >> In Unicode it's code point U+00A0 >> >> In UTF-8 it's encoded as 0xc2 0xa0 >> >> On my system, with Debian's X Compose defaults, I can type one by >> pressing Compose-Space-Space. Here's the relevant snippet from >> /usr/share/X11/locale/en_US.UTF-8/Compose: >> >> # Spaces >>: " " nobreakspace # NO-BREAK >> SPACE >> >> It's one of the first things I look for whenever something is visually >> screwy (along with Carriage Returns). They commonly creep in when someone >> pastes content from a Microsoft product, or from a web site (or both). >> >> > i identified the file is in the main script sourced >> > >> > got a suggestion for a hexdump cmd ? i know of none with args >> >> On Debian, you can use hd (which is the same as hexdump -C). Or od -tx1. >> >>
Re: some unknown bug, says : command not found
On Mon, Nov 01, 2021 at 06:34:45PM +0100, Alex fxmbsw7 Ratchev wrote: > the hd one gives me, i think its the only two cat cases : > > 0410 0a 6d 76 20 2d 2d 20 22 24 74 74 22 20 22 24 74 |.mv -- "$tt" > "$t| > 0420 74 74 22 0a 0a 24 78 62 6c 70 70 20 3c 28 0a 20 |tt"..$xblpp > <(. | > 0430 69 66 20 5b 5b 20 2d 73 20 24 74 20 5d 5d 20 3b |if [[ -s $t ]] > ;| > 0440 20 74 68 65 6e 0a 20 20 63 61 74 20 2d 2d 20 22 | then. cat -- > "| > 0450 24 74 22 0a 20 65 6c 69 66 20 5b 5b 20 2d 73 20 |$t". elif [[ > -s | > 0460 24 74 32 20 5d 5d 20 3b 20 74 68 65 6e 0a 20 20 |$t2 ]] ; > then. | > 0470 63 61 74 20 2d 2d 20 22 24 74 32 22 0a 20 65 6c |cat -- "$t2". > el| > 0480 73 65 0a 20 20 6b 6f 70 69 2e 67 61 77 6b 20 22 |se. kopi.gawk > > i cant really see, i gotta first code me an own hexdump in gawk If you're sure this is the file that's causing the problem, the next step is to figure out which *part* of the file is causing the problem. You're showing a hex dump of one part, but this part looks reasonable, at least as far as characters being within the expected ASCII range.
Re: some unknown bug, says : command not found
Date:Mon, 1 Nov 2021 12:03:48 -0400 From:Greg Wooledge Message-ID: | > bash: : command not found | > bash: : command not found | | Because this is you, I can't be sure whether you are correctly pasting | the output from your terminal into email, Actually, because it is him, it is more likely that he has "cat" aliased to ' ' somehow, since he loves aliases so much. kre
Re: some unknown bug, says : command not found
On Tue, Nov 02, 2021 at 03:23:15AM +0700, Robert Elz wrote: > Date:Mon, 1 Nov 2021 12:03:48 -0400 > From:Greg Wooledge > Message-ID: > > | > bash: : command not found > | > bash: : command not found > | > | Because this is you, I can't be sure whether you are correctly pasting > | the output from your terminal into email, > > Actually, because it is him, it is more likely that he has "cat" aliased > to ' ' somehow, since he loves aliases so much. Not a bad guess, but I can't reproduce it that way: unicorn:~$ bash unicorn:~$ alias cat=' ' unicorn:~$ cat /dev/null bash: /dev/null: Permission denied unicorn:~$ alias cat='' unicorn:~$ cat /dev/null bash: /dev/null: Permission denied Then I tried with a non-breaking space, and that's closer, but unicorn:~$ alias cat=' ' unicorn:~$ cat /dev/null bash: : command not found The "space nbsp space" in that result is interesting, but I don't think that's what he's doing, even accounting for the possiblity that he typed one space where the terminal shows three.
Re: some unknown bug, says : command not found
On Tue, Nov 02, 2021 at 03:23:15AM +0700, Robert Elz wrote: > Date:Mon, 1 Nov 2021 12:03:48 -0400 > From:Greg Wooledge > Message-ID: > > | > bash: : command not found > | > bash: : command not found > | > | Because this is you, I can't be sure whether you are correctly pasting > | the output from your terminal into email, > > Actually, because it is him, it is more likely that he has "cat" aliased > to ' ' somehow, since he loves aliases so much. > > kre > Looking at their trace output, the thing that causes the error is '' /dev/fd/63 The /dev/fd/63 bit is probably from a process substitution. What causes the '' is anyone's guess, and mine is that it's simply a variable that happens to be unset or empty (possibly due to a mistyping in its name?) $ "$my_thnig" <( [[ -s "$pathname" ]] && cat -- "$pathname" ) bash: : command not found -- Andreas (Kusalananda) Kähäri SciLifeLab, NBIS, ICM Uppsala University, Sweden .
Re: some unknown bug, says : command not found
On Mon, Nov 1, 2021, 3:46 PM Greg Wooledge wrote: > On Tue, Nov 02, 2021 at 03:23:15AM +0700, Robert Elz wrote: > > Date:Mon, 1 Nov 2021 12:03:48 -0400 > > From:Greg Wooledge > > Message-ID: > > > > | > bash: : command not found > > | > bash: : command not found > > | > > | Because this is you, I can't be sure whether you are correctly > pasting > > | the output from your terminal into email, > > > > Actually, because it is him, it is more likely that he has "cat" aliased > > to ' ' somehow, since he loves aliases so much. > > Not a bad guess, but I can't reproduce it that way: > > unicorn:~$ bash > unicorn:~$ alias cat=' ' > unicorn:~$ cat /dev/null > bash: /dev/null: Permission denied > unicorn:~$ alias cat='' > unicorn:~$ cat /dev/null > bash: /dev/null: Permission denied > > Then I tried with a non-breaking space, and that's closer, but > > unicorn:~$ alias cat=' ' > unicorn:~$ cat /dev/null > bash: : command not found > > The "space nbsp space" in that result is interesting, but I don't think > that's what he's doing, even accounting for the possiblity that he > typed one space where the terminal shows three. > I only get a non-breaking space and a space between the colons rather than three space characters. >
Re: Possible bug with redirect.
On Tue, 2 Nov 2021 at 02:37, Rikke Rendtorff wrote: > > I'm very new to linux [...] > I went to the https://linuxmint.com community website and joined their IRC > chat to see if they had an explanation and they told me it may be a bug, > since they couldn't reproduce it for other commands. > > P.S. They also told me I may be one of those users that gets myself into > trouble by using commands in ways that no sane person would ever think of. Hi, the advice you have quoted above is entirely wrong, and seems to be completely ignorant of the topic, so I suggest that you disregard *all* of it. There are many different communities with different knowledge and interests, and replies you get can vary in quality depending on who there happens to notice a request for assistance at any given moment. You can find a good resource of quality information on shell command use here: http://mywiki.wooledge.org/ This (bug-bash) mailing list is intended for actual bug reports, not maybe-bugs by folks who don't know what they are doing. If you have questions in future, the best place to ask them is another mailing list run by this community: https://lists.gnu.org/mailman/listinfo/help-bash And just in case you are not subscribed to this mailing list, are you aware that the other aspects of your question have already been answered? If not, you can read them here: https://lists.gnu.org/archive/html/bug-bash/2021-11/msg00010.html
Assignment with colons *should* be tilde expanded in POSIX mode
As you know, POSIX requires tilde expansion following an an unquoted colon in an assignment [1]. A bug was reported [2] against bash 5.1-alpha that the tildes in $ echo foo=~:~ foo=~:~ should not be expanded in POSIX mode, because this is not an assignment. That was fixed in 5.1-beta. However, that fix also seems to have broken the actual assignment $ foo=~:~ $ echo "$foo" /home/anders:~ where both tildes should be expanded in POSIX mode, because this is an assignment. 5.0.18 and 5.1-alpha gave the expected /home/anders:/home/anders, while 5.1-beta, 5.1.8, and the devel branch incorrectly give /home/anders:~. Anders [1] https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_01 [2] https://lists.gnu.org/archive/html/bug-bash/2020-07/msg00072.html
Re: some unknown bug, says : command not found
Date:Mon, 1 Nov 2021 16:31:51 -0400 From:Greg Wooledge Message-ID: | unicorn:~$ alias cat=' ' no I meant alias cat="' '" though which quote in inside doesn't matter, and using \ quoting is possible too nx$ alias xx='\ ' jinx$ xx -bash: : command not found kre
Re: some unknown bug, says : command not found
to answer around what was written, i dont have a cat alias but what mr andreas wrote seems much similiar to what i do, process sub.. ill check the vars carefully but i dont get it fully but, on your all tries to produce command not found, can u set -x the tries, .. in mine it shows cat ... then command not found, like the cat is gone somehow means does yours produce a + cat ( or cmd ) and then just display command not found ill check the vars as i have on the left side of the command sub vars and on the inner side thank you's On Mon, Nov 1, 2021, 23:08 Andreas Kusalananda Kähäri wrote: > On Tue, Nov 02, 2021 at 03:23:15AM +0700, Robert Elz wrote: > > Date:Mon, 1 Nov 2021 12:03:48 -0400 > > From:Greg Wooledge > > Message-ID: > > > > | > bash: : command not found > > | > bash: : command not found > > | > > | Because this is you, I can't be sure whether you are correctly > pasting > > | the output from your terminal into email, > > > > Actually, because it is him, it is more likely that he has "cat" aliased > > to ' ' somehow, since he loves aliases so much. > > > > kre > > > > Looking at their trace output, the thing that causes the error is > > '' /dev/fd/63 > > The /dev/fd/63 bit is probably from a process substitution. > > What causes the '' is anyone's guess, and mine is that it's simply a > variable that happens to be unset or empty (possibly due to a mistyping > in its name?) > > $ "$my_thnig" <( [[ -s "$pathname" ]] && cat -- "$pathname" ) > bash: : command not found > > > > -- > Andreas (Kusalananda) Kähäri > SciLifeLab, NBIS, ICM > Uppsala University, Sweden > > . > >
Re: some unknown bug, says : command not found
i dont see the 63, its inside that tho i post the code, as i saw its fairly short, 'xbl' file the tgz with required awks and support files is also sent but anyway in the xbl the affected part are the cat or kopi.gawk if parts inside $xblpp <( here ) $xblpp is either cat or . cat for 'display me the code' and defaultly . for 'source the code, not display' $t and $t2 are just stamps, as seen in my set -x post i think this error came up recently just, it happens when i . xbl too new bash seasion sources it right without err, i never seen this err before too bash 5.1.8 debian release i think its some bug.. what else could it be, .. new bash sessions source it right, also before this err really wasnt, not that i tried . script instead of new bash sessions much .. On Mon, Nov 1, 2021, 23:08 Andreas Kusalananda Kähäri wrote: > On Tue, Nov 02, 2021 at 03:23:15AM +0700, Robert Elz wrote: > > Date:Mon, 1 Nov 2021 12:03:48 -0400 > > From:Greg Wooledge > > Message-ID: > > > > | > bash: : command not found > > | > bash: : command not found > > | > > | Because this is you, I can't be sure whether you are correctly > pasting > > | the output from your terminal into email, > > > > Actually, because it is him, it is more likely that he has "cat" aliased > > to ' ' somehow, since he loves aliases so much. > > > > kre > > > > Looking at their trace output, the thing that causes the error is > > '' /dev/fd/63 > > The /dev/fd/63 bit is probably from a process substitution. > > What causes the '' is anyone's guess, and mine is that it's simply a > variable that happens to be unset or empty (possibly due to a mistyping > in its name?) > > $ "$my_thnig" <( [[ -s "$pathname" ]] && cat -- "$pathname" ) > bash: : command not found > > > > -- > Andreas (Kusalananda) Kähäri > SciLifeLab, NBIS, ICM > Uppsala University, Sweden > > . > > xbl Description: Binary data xbl5.tgz Description: application/gtar-compressed
Re: some unknown bug, says : command not found
.. regarding a $notset <( .. wouldnt that display in set -x on that line, rather when the cat or gawk is ran On Tue, Nov 2, 2021, 06:03 Alex fxmbsw7 Ratchev wrote: > i dont see the 63, its inside that tho > > i post the code, as i saw its fairly short, 'xbl' file > the tgz with required awks and support files is also sent > > but anyway in the xbl the affected part are the cat or kopi.gawk if parts > inside $xblpp <( here ) > > $xblpp is either cat or . > cat for 'display me the code' and defaultly . for 'source the code, not > display' > $t and $t2 are just stamps, as seen in my set -x post > > i think this error came up recently just, it happens when i . xbl too > new bash seasion sources it right without err, i never seen this err > before too > bash 5.1.8 debian release > > i think its some bug.. what else could it be, .. new bash sessions source > it right, also before this err really wasnt, not that i tried . script > instead of new bash sessions much > > .. > > On Mon, Nov 1, 2021, 23:08 Andreas Kusalananda Kähäri < > andreas.kah...@abc.se> wrote: > >> On Tue, Nov 02, 2021 at 03:23:15AM +0700, Robert Elz wrote: >> > Date:Mon, 1 Nov 2021 12:03:48 -0400 >> > From:Greg Wooledge >> > Message-ID: >> > >> > | > bash: : command not found >> > | > bash: : command not found >> > | >> > | Because this is you, I can't be sure whether you are correctly >> pasting >> > | the output from your terminal into email, >> > >> > Actually, because it is him, it is more likely that he has "cat" aliased >> > to ' ' somehow, since he loves aliases so much. >> > >> > kre >> > >> >> Looking at their trace output, the thing that causes the error is >> >> '' /dev/fd/63 >> >> The /dev/fd/63 bit is probably from a process substitution. >> >> What causes the '' is anyone's guess, and mine is that it's simply a >> variable that happens to be unset or empty (possibly due to a mistyping >> in its name?) >> >> $ "$my_thnig" <( [[ -s "$pathname" ]] && cat -- "$pathname" ) >> bash: : command not found >> >> >> >> -- >> Andreas (Kusalananda) Kähäri >> SciLifeLab, NBIS, ICM >> Uppsala University, Sweden >> >> . >> >>
