Re: [PATCH] added -- in autocd
On Tue, 2015-04-28 at 21:27 +0200, isabella parakiss wrote: > I'm sorry, I added a link to a pastebin in my previous message but > it's not available anymore. > Anyway, this was the content (posted by Score_Under in #bash): > > I think -- should enter said directory. > I hope it's ok... It may be easier to visualize in a different order: score@kirisame ~/downloads $ shopt -s autocd score@kirisame ~/downloads $ -- bash: --: command not found score@kirisame ~/downloads $ mkdir -- -- score@kirisame ~/downloads $ -- cd -- score@kirisame ~ $ pwd /home/kirisame Expected outcome: To be in /home/kirisame/downloads/-- And yes, I agree it's a bug and should have entered there.
bash --debugger on a script with no arguments
It's come to my attention that running bash --debugger doesn't source DEBUGGER_START_FILE when the script to be debugged isn't followed by any arguments. An example will probably make this clear. Suppose */tmp/foo.sh* is: echo hi And you run: bash --debugger /tmp/foo.sh I get "hi" printed without DEBUGGER_START_FILE sourced. However it is sourced if I run bash --debugger /tmp/foo.sh "" Investigating why this might be, I see this in bash/shell.c at line 724: if (debugging_mode && locally_skip_execution == 0 && running_setuid == 0 && dollar_vars[1]) start_debugger (); I can see why you wouldn't want to source DEBUGGER_START_FILE if a script name (/tmp/foo.sh) were not given, but I'm not sure why you would want to skip if it didn't have an argument. So shouldn't the end of that test be dollar_vars[0] instead? Thanks.
Re: [PATCH] added -- in autocd
On 4/28/15 2:44 PM, isabella parakiss wrote:
> ---
> execute_cmd.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/execute_cmd.c b/execute_cmd.c
> index e3aa37f..51c29c6 100644
> --- a/execute_cmd.c
> +++ b/execute_cmd.c
> @@ -4283,6 +4283,7 @@ run_builtin:
>
>if (autocd && interactive && words->word && is_dirname (words->word->word))
> {
> + words = make_word_list (make_word ("--"), words);
>words = make_word_list (make_word ("cd"), words);
>xtrace_print_word_list (words, 0);
>goto run_builtin;
Thanks, this is a good idea and the right fix.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
"autocd" shell option breaks on dir names beginning with hyphen
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-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong --param=ssp-buffer-size=4 -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin' -DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc' -DSYS_BASH_LOGOUT='/etc/bash.bash_logout' uname output: Linux kirisame 3.19.3.201504021826-1-grsec #1 SMP PREEMPT Mon Apr 13 05:57:41 BST 2015 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.3 Patch Level: 33 Release Status: release Description: While "autocd" is active, giving bash the name of a directory beginning with a dash will cause that directory to be interpreted as a switch to "cd". Repeat-By: 1. $ mkdir test_dir && cd test_dir 2. $ mkdir -- -- 3. $ shopt -s autocd 4. Note current working directory 5. $ -- 6. Note current working directory. It should be [...]/test_dir/--, but it is your home directory. signature.asc Description: OpenPGP digital signature
Re: [PATCH] added -- in autocd
On 4/28/15, Eric Blake wrote:
> On 04/28/2015 12:44 PM, isabella parakiss wrote:
>> ---
>
> Might have been nice to leave a comment why you propose this change. It
> looks like it is needed for the case when autocd mode is on and you type
> the name of a directory that starts with '-', where the cd command needs
> to interpret the argument as a directory name rather than an option.
>
>> execute_cmd.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/execute_cmd.c b/execute_cmd.c
>> index e3aa37f..51c29c6 100644
>> --- a/execute_cmd.c
>> +++ b/execute_cmd.c
>> @@ -4283,6 +4283,7 @@ run_builtin:
>>
>>if (autocd && interactive && words->word && is_dirname
>> (words->word->word))
>> {
>> + words = make_word_list (make_word ("--"), words);
>>words = make_word_list (make_word ("cd"), words);
>>xtrace_print_word_list (words, 0);
>>goto run_builtin;
>>
>
> --
> Eric Blake eblake redhat com+1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>
>
I'm sorry, I added a link to a pastebin in my previous message but it's
not available anymore.
Anyway, this was the content (posted by Score_Under in #bash):
score@kirisame ~/downloads $ mkdir -- --
score@kirisame ~/downloads $ shopt -s autocd
score@kirisame ~/downloads $ --
cd --
score@kirisame ~ $ cd downloads/
score@kirisame ~/downloads $ rmdir -- --
score@kirisame ~/downloads $ --
bash: --: command not found
score@kirisame ~/downloads $
I think -- should enter said directory.
I hope it's ok...
---
xoxo iza
Re: [PATCH] added -- in autocd
On 04/28/2015 12:44 PM, isabella parakiss wrote:
> ---
Might have been nice to leave a comment why you propose this change. It
looks like it is needed for the case when autocd mode is on and you type
the name of a directory that starts with '-', where the cd command needs
to interpret the argument as a directory name rather than an option.
> execute_cmd.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/execute_cmd.c b/execute_cmd.c
> index e3aa37f..51c29c6 100644
> --- a/execute_cmd.c
> +++ b/execute_cmd.c
> @@ -4283,6 +4283,7 @@ run_builtin:
>
>if (autocd && interactive && words->word && is_dirname (words->word->word))
> {
> + words = make_word_list (make_word ("--"), words);
>words = make_word_list (make_word ("cd"), words);
>xtrace_print_word_list (words, 0);
>goto run_builtin;
>
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
[PATCH] added -- in autocd
---
execute_cmd.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/execute_cmd.c b/execute_cmd.c
index e3aa37f..51c29c6 100644
--- a/execute_cmd.c
+++ b/execute_cmd.c
@@ -4283,6 +4283,7 @@ run_builtin:
if (autocd && interactive && words->word && is_dirname (words->word->word))
{
+ words = make_word_list (make_word ("--"), words);
words = make_word_list (make_word ("cd"), words);
xtrace_print_word_list (words, 0);
goto run_builtin;
--
2.3.6
This was reported in #bash: http://p.pomf.se/7215
---
xoxo iza
Re: PROMPT_COMMAND causing strange cursor behavior
On 04/28/2015 08:26 AM, Chet Ramey wrote: On 4/27/15 1:26 PM, Martin Sebor wrote: Bash Version: 4.3 Patch Level: 33 Release Status: release Description: When the PROMPT_COMMAND variable is set to a command such a printf it causes the cursor to jump to disappear or jump to the wrong positions when typing text that spans more than physical terminal line. The problem exists in at least Bash 4.2 and 4.3 (but likely earlier versions as well). This isn't exactly a bug. If readline doesn't know where the cursor is when it starts to perform redisplay, it's not going to be able to put the cursor in the right position. Readline assumes that cursor starts in column 0 and makes redisplay decisions based on that. Yes, I subsequently found a report of a similar problem here: http://lists.gnu.org/archive/html/bug-bash/2009-03/msg4.html It seems that PROMPT_COMMAND shouldn't (isn't intended to) be used for commands that produce output. If that's so, may I suggest to mention it in the manual? Otherwise, the trouble is that there are tools that use the variable for just that purpose. Thanks Martin
Re: PROMPT_COMMAND causing strange cursor behavior
On 4/27/15 1:26 PM, Martin Sebor wrote: > Bash Version: 4.3 > Patch Level: 33 > Release Status: release > > Description: > When the PROMPT_COMMAND variable is set to a command such a printf > it causes the cursor to jump to disappear or jump to the wrong > positions when typing text that spans more than physical terminal > line. The problem exists in at least Bash 4.2 and 4.3 (but likely > earlier versions as well). This isn't exactly a bug. If readline doesn't know where the cursor is when it starts to perform redisplay, it's not going to be able to put the cursor in the right position. Readline assumes that cursor starts in column 0 and makes redisplay decisions based on that. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
