Your message dated Tue, 27 Jan 2015 23:13:18 -0400 with message-id <20150128031318.gm29...@cordes.ca> and subject line Re: [775661] additional info to "odd completion candidates" has caused the Debian Bug report #775661, regarding [bash-completion] odd completion candidates to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 775661: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775661 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---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?
--- End Message ---
--- Begin Message ---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
Description: Digital signature
--- End Message ---
_______________________________________________ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/bash-completion-devel
