Debian Bug report logs - #775661
[bash-completion] odd completion candidates

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: lumin <cdluminate@gmail.com>

To: submit <submit@bugs.debian.org>

Subject: [bash-completion] odd completion candidates

Date: Sun, 18 Jan 2015 10:22:20 +0000

Package: bash-completion
Version: 1:2.1-4

Hi,

Accidently I found this bug/issue after typing 2 times of the TAB key.

REPLAY:
1. create files in a dir
$ ll
total 472K
-rw-r--r-- 1 x x 201K Jan 18 10:13 linux?.0
-rw-r--r-- 1 x x 113K Jan 18 10:13 linux?.1
-rw-r--r-- 1 x x 151K Jan 18 10:13 linux?.2

2. cat +{2 times of tab}
$ cat 
.0     .1     .2     linux  
In fact, the same result would appear after s/cat/vim/ or
something like that.

Maybe this is just cosmetic, but it is
strange, isn't it?

Message #10 received at 775661@bugs.debian.org (full text, mbox, reply):

From: Ville Skyttä <ville.skytta@iki.fi>

To: 775661@bugs.debian.org

Subject: Re: odd completion candidates

Date: Sun, 18 Jan 2015 21:49:01 +0200

FWIW, I cannot reproduce with current upstream bash-completion git
with bash 4.2.53(1) or 4.3.33(1) on Fedora 20.

Message #15 received at 775661@bugs.debian.org (full text, mbox, reply):

From: Peter Cordes <peter@cordes.ca>

To: bash-completion-devel@lists.alioth.debian.org, 775661@bugs.debian.org

Subject: Re: [Bash-completion-devel] Bug#775661: [bash-completion] odd completion candidates

Date: Mon, 19 Jan 2015 17:07:31 -0400

On Sun, Jan 18, 2015 at 10:22:20AM +0000, lumin wrote:
> Package: bash-completion
> Version: 1:2.1-4
> 
> Hi,
> 
> Accidently I found this bug/issue after typing 2 times of the TAB key.
> 
> REPLAY:
> 1. create files in a dir
> $ ll
> total 472K
> -rw-r--r-- 1 x x 201K Jan 18 10:13 linux?.0
> -rw-r--r-- 1 x x 113K Jan 18 10:13 linux?.1
> -rw-r--r-- 1 x x 151K Jan 18 10:13 linux?.2
> 
> 2. cat +{2 times of tab}
> $ cat 
> .0     .1     .2     linux  
> In fact, the same result would appear after s/cat/vim/ or
> something like that.
> 
> Maybe this is just cosmetic, but it is
> strange, isn't it?

 The progcomp code doesn't try to escape cursor-movement control or
escape codes, I don't think, but GNU ls does.  I think your filenames
are linux^M.x or something.

ls  --literal
              print raw entry names (don't treat e.g. control
characters specially)

 might give similar output to tab completion.

Did those filenames come from something that read from a DOS text
file?  Stripped off the trailing linefeed, was left with "linux^M".

 If you truncate those files (> linux*0; > linux*1; ...), and make a
tar.gz of your directory as a testcase, that might possibly be useful
for us to test progcomp with weird input.

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC

Message #20 received at 775661@bugs.debian.org (full text, mbox, reply):

From: lumin <cdluminate@gmail.com>

To: 775661@bugs.debian.org

Cc: ville.skytta@iki.fi, peter@cordes.ca

Subject: [775661] additional info to "odd completion candidates"

Date: Wed, 28 Jan 2015 01:36:20 +0000

I'm sorry to reply so late.

In fact, these 3 files were generated from one of my python scripts.

-rw-r--r-- 1 x x 201K Jan 18 10:13 linux?.0
-rw-r--r-- 1 x x 113K Jan 18 10:13 linux?.1
-rw-r--r-- 1 x x 151K Jan 18 10:13 linux?.2

And I then found that, the "?" displayed in filename field denotes '\n'.
at the beginning I tried to fix the issue in my script:

f = open (filename.replace('?', ''), 'w+') [0]

but it doesn't work. however another replace action

f = open (filename.replace('\n', ''), 'w+') [1]

really kills that odd character.

thank you,
Ville Skyttä
Peter Cordes
for looking into this issue.

[0] where "filename" is a string object, the method "replace" does
replacement in the string.
[1] means delete all the newline character.
-- 
 .''`.    
: :' :    
`. `'     
  `-      

Message #25 received at 775661@bugs.debian.org (full text, mbox, reply):

From: lumin <cdluminate@gmail.com>

To: 775661@bugs.debian.org

Cc: ville.skytta@iki.fi, peter@cordes.ca

Subject: Re: [775661] additional info to "odd completion candidates"

Date: Wed, 28 Jan 2015 01:55:06 +0000

I extracted the lines of python code below,
 which contribute to this issue.

:)
Thanks.

foo.py
-------------------------------
|#!/usr/bin/python3.4
|# -*- Coding: UTF-8 -*-
|
|for i in range (3):
|	with open ("linux" + "\n." + str(i), "w+") as f:
|		f.write(" ")
--------------------------------

-- 
 .''`.    
: :' :    
`. `'     
  `-      

Message #30 received at 775661-close@bugs.debian.org (full text, mbox, reply):

From: Peter Cordes <peter@cordes.ca>

To: 775661-close@bugs.debian.org, lumin <cdluminate@gmail.com>, ville.skytta@iki.fi

Subject: Re: [775661] additional info to "odd completion candidates"

Date: Tue, 27 Jan 2015 23:13:18 -0400

[Message part 1 (text/plain, inline)]

On Wed, Jan 28, 2015 at 01:55:06AM +0000, lumin wrote:
> I extracted the lines of python code below,
>  which contribute to this issue.
> 
> :)
> Thanks.
> 
> foo.py
> -------------------------------
> |#!/usr/bin/python3.4
> |# -*- Coding: UTF-8 -*-
> |
> |for i in range (3):
> |	with open ("linux" + "\n." + str(i), "w+") as f:
> |		f.write(" ")
> --------------------------------

 Ok, that explains how the newlines got there.

 The programable completion code uses constructs like
COMP_REPLY=( $(compgen ...) )  # array variable
all over the place, and similar constructs that aren't newline-clean.
There's actually no way to use the compgen built-in safely with
filenames containing newlines, because its output uses newline as a
record separator.   

 So in summary, it's a bad idea to ever put newlines in filenames on
purpose, because many shell scripts will break when handling them.

http://mywiki.wooledge.org/BashFAQ/020 and other FAQ questions
describe how to write shell code that doesn't break, but it's not
common practice.

 Closing the Debian bug since this is expected behaviour that can't be
fixed without redesigning bash's compgen builtin.

-- 
#define X(x,y) x##y
Peter Cordes ;  e-mail: X(peter@cor , des.ca)

"The gods confound the man who first found out how to distinguish the hours!
 Confound him, too, who in this place set up a sundial, to cut and hack
 my day so wretchedly into small pieces!" -- Plautus, 200 BC

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.