Command name dequote does not work

[ingo . krabbe]

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-pc-linux-gnu' 
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL 
-DHAVE_CONFIG_H   -I.  -I../bash -I../bash/include -I../bash/lib  
-D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat 
-Werror=format-security -Wall
uname output: Linux k210app1 3.2.0-4-amd64 #1 SMP Debian 3.2.46-1 x86_64 
GNU/Linux
Machine Type: x86_64-pc-linux-gnu

Bash Version: 4.2
Patch Level: 37
Release Status: release

Description:
I wrote a simple shell script using sed to convert \n into newlines and 
other \\(.) to \\\1 and called that script dequote.
When I'm trying to call it nothing happens, when I'm calling $HOME/bin/dequote 
it works. There's no alias called dequote, there's no other dequote in path.
When I rename the script and call it it just works as expected.

This looks like a secret command, that just echos its arguments, as calling 
"dequote xyz" echoes "xyz".

But having a secret alias or command is very evil. What's up here?


Repeat-By:
see above

Fix:
DonÃ't use secret commands. Any builtin has to be documented on the 
help page.

Re: Command name dequote does not work

[ingo . krabbe]

I finally found it. I forgot to check the function names. It's a function of 
bash-completion, though I don't think that such a function name should be 
exported.
--- Begin Message ---
Not sure we have enough info here. Have you tried "set -x" to see what's really 
going on? Have you also confirmed that it isn't actually calling your script 
and the script simply isn't functioning as expected?
-- 
Dan Douglas--- End Message ---

Re: The Manual about the MAIL environment is misleading

[Ingo Krabbe]

Hi Chet,

thank you for your answer. I will send a summary about this problem to the 
gentoo maintainers, then.

Best Regards,

Ingo


> On 7/13/16 8:37 AM, ikrabbe@gmail.com wrote:
> 
>> Bash Version: 4.3
>> Patch Level: 42
>> Release Status: release
>> 
>> Description:
>>  In a bash session where the MAIL variable is not explicitly set, the 
>> MAIL variable might be auto-set through a compile time definition of 
>> DEFAULT_MAIL_DIRECTORY. There is no method (no method I know of) to find 
>> about about these compile time definitions and / or configuration flags.
>>  To find out about this bevaiour I needed to read the source code and 
>> finally found this line in CHANGES:
>> 
>>  hhh. Improved the mail checking code so it won't check (and possibly 
>> cause an
>>   NFS file system mount) until MAILPATH or MAIL is given a value -- 
>> there
>>   is no default if DEFAULT_MAIL_DIRECTORY is not defined at compile 
>> time.
>>  
>> 
>> Repeat-By:
>>  Install bash and remove all occurences of MAIL= or similar from the 
>> several profile and rc files.
>> 
>> Fix:
>>  Please describe the dependency of the MAIL variables on the manual 
>> page. If you manage to do so, add the value of DEFAULT_MAIL_DIRECTORY and 
>> it's effects in the generated manual pages.
> 
> The precedence of the MAIL and MAILPATH variables is already described in
> the man page.  I will look at changes to the man page to indicate that
> there is no default value for MAILPATH; there is some language in there
> that implies bash sets a default value (which it did in the past).
> 
> The manual page describes bash as I distribute it.  If a vendor or
> distribution wishes to change the default, to supply a default for
> MAILPATH, for example, I expect them to modify the documentation for
> their distribution to reflect that.  Some do, many don't.
> 
> -- 
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/