completion fails on a filename that contains an equal character
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-redhat-linux-gnu' -DCONF_VENDOR='redhat' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic uname output: Linux cws013 3.10.0-957.5.1.el7.x86_64 #1 SMP Wed Dec 19 10:46:58 EST 2018 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-redhat-linux-gnu Bash Version: 4.2 Patch Level: 46 Release Status: release Description: The bash [tab] completion as found on redhat RHEL7.6 fails with a filename that has the = character. This happens when there are multiple matches for the part before the = character. The behavior is correct when there is only one match, or when the readline 'complete-filename' is invoqued using "meta /" Repeat-By: touch foo=bar touch foobaz #type ls foo= #press [tab] to get completion ls foo=foo\=bar ls: cannot access foo=foo=bar: No such file or directory
Re: completion fails on a filename that contains an equal character
On 3/6/19 7:59 AM, adff wrote: > Bash Version: 4.2 > Patch Level: 46 > Release Status: release > > Description: > The bash [tab] completion as found on redhat RHEL7.6 fails with a > filename that has the = character. This happens when there are multiple > matches for the part before the = character. > The behavior is correct when there is only one match, or when the > readline 'complete-filename' is invoqued using "meta /" > > > Repeat-By: > touch foo=bar > touch foobaz > #type > ls foo= > #press [tab] to get completion > ls foo=foo\=bar > ls: cannot access foo=foo=bar: No such file or directory This is because the `=' is one of the characters that breaks words for the readline word completion code. Bash allows you to change the set of word break characters by changing the value of the COMP_WORDBREAKS variable. If you don't want to do that, you can quote the `=' with a backslash to get one-time completion. bash-4.2 is pretty old, but when I try to complete after the `=', I get `foo=foo'. Programmable completion may change the results. -- ``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: Bash forgets sourcefile and linenumber of read-in functions
On 3/5/19 12:13 AM, L A Walsh wrote: >> OK, doing that doesn't reveal any problem. If you add >> shopt -s extdebug; declare -F addnums >> to prog.sh, it prints >> >> addnums 0 environment >> > That it prints 'environment' and '0' are issues as the manpage says: > >the -F option to declare or typeset >will list the function names only (and optionally the source file >and line number, if the extdebug shell option is enabled). > > Following those instructions, I enabled the extdebug option before > the function was defined -- I set a null DEBUG handler just so > if bash called a DEBUG handler, then I'd make sure to return 0 so > nothing would be skipped. And...then I find out that 'extdebug' > also starts the bash debugger. > > Except that the bash debugger gets lost on files that don't > have a real source file name. Environment is not the name of the file > containing the function -- it is a nebulous, ephemeral area of a > process -- but it certainly is not the repository for source files > that configure bash's behavior. If you don't want functions to appear in the environment, don't put them in the environment. Bash is reporting accurately where it read the definition for `addnums'. >> which is correct: the shell read the definition of addnums from the >> environment, > Except... how did it get into the environment/ It wasn't there when > bash started. Bash created a COPY there -- but the COPY is not > a SOURCE file. You exported it, putting it into the environment, losing the file and line information. > > There's no way you can convincingly say that you believe the source came > out of nothing into bashes environment, so we'll hopefully avoid > that topic as well as bash "being the way it is" due to being kidnapped > by space aliens. This is gibberish. > > Of course the debugger could recover here if bash had kept the > actual source lines of the function as they were read in, but, as you > mention, it would take more memory. This is nonsense, unless you want to pass this hypothetical original text through the environment as well. > > But bashdb doesn't work reliably without, at least being able to find > the source. So the subject of that thread changed to: > > "Please store source file name + line number for all functions >defined whether or not bashdb is running." > > Which lead to your assertion that it did, except neither I nor the > debugger can accept 'environment line 0' as a useful source file + line > number at which we can find the definition of the function we want to > step through. OK, then don't use the environment to pass functions you want to step through. If you want to do that, accept that you have deliberately defeated the bashdb feature you want to use. -- ``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/
Issue about AIX
Hi,
On AIX, like Solaris, when root, the test "test -x /tmp/AFile" returns true
even if the file is not executable.
This issue is there for ages.
Here attached is the patch for fixing it for v5.0 .
Would you mind adding it to the source code of bash ?
Thanks/Regards,
Tony
--- ./lib/sh/eaccess.c.ORIGIN 2019-03-06 16:15:23 +0100
+++ ./lib/sh/eaccess.c 2019-03-06 16:16:20 +0100
@@ -213,10 +213,10 @@
# else /* HAVE_EACCESS */ /* FreeBSD */
ret = eaccess (path, mode); /* XXX -- not always correct for X_OK */
# endif /* HAVE_EACCESS */
-# if defined (__FreeBSD__) || defined (SOLARIS)
+# if defined (__FreeBSD__) || defined (SOLARIS) || defined(_AIX)
if (ret == 0 && current_user.euid == 0 && mode == X_OK)
return (sh_stataccess (path, mode));
-# endif /* __FreeBSD__ || SOLARIS */
+# endif /* __FreeBSD__ || SOLARIS || _AIX */
return ret;
#elif defined (EFF_ONLY_OK) /* SVR4(?), SVR4.2 */
return access (path, mode|EFF_ONLY_OK);
@@ -232,7 +232,7 @@
if (current_user.uid == current_user.euid && current_user.gid == current_user.egid)
{
ret = access (path, mode);
-#if defined (__FreeBSD__) || defined (SOLARIS)
+#if defined (__FreeBSD__) || defined (SOLARIS) || defined(_AIX)
if (ret == 0 && current_user.euid == 0 && mode == X_OK)
return (sh_stataccess (path, mode));
#endif
Re[2]: history -a misbehaves with $HISTSIZE
> It's in the devel branch. Try it and see if it does what you want. Yes, it does. Thanks! >Пятница, 1 марта 2019, 19:44 +03:00 от Chet Ramey : > >On 2/28/19 5:53 PM, Айрат Васбикарамов wrote: >>> It seems like what you want is min(history_lines_this_session, >>> history_offset), >>> kind of like what you say below. Try the attached patch and see if it >>> does what you want. >> >> Yes, that's what I mean. >> >>> I don't think this would happen too much in practice, though, because if >>> you wait until you have more than $HISTSIZE history entries, you'll lose >>> information no matter what you use. >> >> I don't think that happens frequent either. But it's possible. Someone set >> HISTSIZE to 1000 as he don't care about too old commands and it's happened >> that he typed more than 1000 command. Then he run "history -a" to >> synchronize current history with another started bash for example. And lost >> recent commands. Possibly he notice it. But may not. >> >> Anyway I don't see downsides of this behavior comparing to current. And it >> seems more intuitive to me. So should it be default? > >It's in the devel branch. Try it and see if it does what you want. > >Chet > >-- >``The lyf so short, the craft so long to lerne.'' - Chaucer >``Ars longa, vita brevis'' - Hippocrates >Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/ -- Airat Vasbikaramov
Re: Issue about AIX
On 3/6/19 10:22 AM, REIX, Tony wrote: > Hi, > > > On AIX, like Solaris, when root, the test "test -x /tmp/AFile" returns true > even if the file is not executable. > > This issue is there for ages. > > Here attached is the patch for fixing it for v5.0 . Thanks. Is this true for all versions of AIX? -- ``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/
