Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > gnu.bash.bug > #16312

Could we have GLOBIGNORE ignore . and .. in subdirectories, too?

Path csiph.com!goblin2!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail
From Ilkka Virta <itvirta@iki.fi>
Newsgroups gnu.bash.bug
Subject Could we have GLOBIGNORE ignore . and .. in subdirectories, too?
Date Thu, 28 May 2020 19:02:18 +0300
Lines 27
Approved bug-bash@gnu.org
Message-ID <mailman.546.1590681747.2541.bug-bash@gnu.org> (permalink)
References <1ced5397-877f-a3b9-4ff1-8c08d0065c7a@iki.fi>
NNTP-Posting-Host lists.gnu.org
Mime-Version 1.0
Content-Type text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding 7bit
X-Trace usenet.stanford.edu 1590681747 23701 209.51.188.17 (28 May 2020 16:02:27 GMT)
X-Complaints-To action@cs.stanford.edu
To "bash.bug list" <bug-bash@gnu.org>
Envelope-to bug-bash@gnu.org
User-Agent Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
Content-Language en-US
X-SASI-RCODE 200
DKIM-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; h=to:from:subject:message-id:date:mime-version:content-type:content-transfer-encoding; s=smtp; bh=mzF9KGYUIIKuxulc/cE8p8ExK1SeX3cAG6ox+hQaG0c=; b=AxkSBZJYMwpkvBS2ix/nfIyWtMpO/BldtZvbVY+Mmot5MsnKpILCaqqyQeQGnjI+wizmkSkke/qDRPf3dvWQM6F3JC0Kt4Ta53/WNYP9i1m3BJDpQ0N32Q3G4iBy4qz2F63cXq00b2vMeu1EMfgYLYm+2oTZGsya6bYaX6q+hQRLA+ElOJdryKT5AuwYDByCLeCseJK/ZsZOJ6G/27JSxO/GhU5MHiONNyzCU8Uzbz+rEnjwPyRvC9LosZKvGcoGBisJ3WqNF6HwVBdd8Lzvg/6u0LWCauVTR+PGKUhAkl49eGJFkux8s9F225jCFAPk/3ZkfLJiCKYJuHfnY/nntg==
Received-SPF neutral client-ip=157.24.2.213; envelope-from=itvirta@iki.fi; helo=smtp-in-1.cc.lut.fi
X-detected-operating-system by eggs.gnu.org: First seen = 2020/05/28 12:02:18
X-ACL-Warn Detected OS = FreeBSD 8.x
X-Spam_score_int -32
X-Spam_score -3.3
X-Spam_bar ---
X-Spam_report (-3.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NEUTRAL=0.779, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN
X-Spam_action no action
X-BeenThere bug-bash@gnu.org
X-Mailman-Version 2.1.23
Precedence list
List-Id Bug reports for the GNU Bourne Again SHell <bug-bash.gnu.org>
List-Unsubscribe <https://lists.gnu.org/mailman/options/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=unsubscribe>
List-Archive <https://lists.gnu.org/archive/html/bug-bash>
List-Post <mailto:bug-bash@gnu.org>
List-Help <mailto:bug-bash-request@gnu.org?subject=help>
List-Subscribe <https://lists.gnu.org/mailman/listinfo/bug-bash>, <mailto:bug-bash-request@gnu.org?subject=subscribe>
X-Mailman-Original-Message-ID <1ced5397-877f-a3b9-4ff1-8c08d0065c7a@iki.fi>
Xref csiph.com gnu.bash.bug:16312

Show key headers only | View raw


Let's say I want to glob just the files with names starting with dots, 
but not the ubiquitous dot and dot-dot entries, which are seldom a 
useful result of a glob.

That can be done with something like   ..?* .[!.]*   or   .!(|.)   with 
extglob. Both are still a bit annoying to type, and it would be nice to 
just have  .*  do this directly. GLOBIGNORE seems like it could help, 
but it appears the automatic hiding of . and .. only works with globs 
without a path element:  .*  doesn't generate them, but   ./.*   does.

I could add  GLOBIGNORE=.:..:*/.:*/..  to catch them also in 
subdirectories, but then of course that doesn't work for 
sub-sub-directories, etc.


Could it be possible to extend GLOBIGNORE or some other option to have
globs like  foo/.*   not generate  . and .. as the final part of the 
path regardless of the level they are in?

When given explicitly, without a glob in the final part of the path, 
they should probably still be allowed, even if the word was otherwise a 
glob. (e.g. if something like  foo/*/.  happened to be useful in some case.)


-- 
Ilkka Virta / itvirta@iki.fi

Back to gnu.bash.bug | Previous | Next | Find similar


Thread

Could we have GLOBIGNORE ignore . and .. in subdirectories, too? Ilkka Virta <itvirta@iki.fi> - 2020-05-28 19:02 +0300

csiph-web