Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #16815
| Path | csiph.com!goblin1!goblin.stu.neva.ru!usenet.stanford.edu!not-for-mail |
|---|---|
| From | worley@alum.mit.edu (Dale R. Worley) |
| Newsgroups | gnu.bash.bug |
| Subject | Re: Is this a bug? |
| Date | Tue, 25 Aug 2020 22:09:59 -0400 |
| Lines | 40 |
| Approved | bug-bash@gnu.org |
| Message-ID | <mailman.1276.1598407824.2469.bug-bash@gnu.org> (permalink) |
| References | <145044955.7635963.1598401276773@mail.yahoo.com> <87o8mynonc.fsf@hobgoblin.ariadne.com> |
| NNTP-Posting-Host | lists.gnu.org |
| X-Trace | usenet.stanford.edu 1598407825 23871 209.51.188.17 (26 Aug 2020 02:10:25 GMT) |
| X-Complaints-To | action@cs.stanford.edu |
| Cc | chet.ramey@case.edu, bug-bash@gnu.org |
| To | George R Goffe <grgoffe@yahoo.com> |
| Envelope-to | bug-bash@gnu.org |
| DKIM-Signature | v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcastmailservice.net; s=20180828_2048; t=1598407815; bh=Ulg3h6Vhgnjy6XxQsUZqXxhRCxVlFBmz8Hp1tulb+vk=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=USh2UQW90EmBx8c7i5S2OrUK68wNR0pOI5VbpvKj0zH2Pg0S03MhgT3jDf47GKZxJ LDZoV5RbkQQn7yrwmzD789KO7IrWcljxCPPHSmt1jY6362irkIKoTZ1Z+zn/Ejcyp1 ctn60DYWyDIO4WKBhwZK3fncBa3IvOanmd5NSWevb8E5SOXXUj0Z/EumeosUaSagBI qKjoGv7XINO5y7Moz0DWQ8YcWbuUCTB9fHp6JDJS6gfo3UyDSZYDZVa73LoXGuL+Ea GOLctj0QTJS/EJgEWfUFs8Z0cNEa82PgJU10j5hGiVLtdy23BeIw9XrzMMghDzqiuF D+h3uA0/IYgJg== |
| X-Xfinity-VMeta | sc=-100.00;st=legit |
| X-Authentication-Warning | hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f |
| In-Reply-To | <145044955.7635963.1598401276773@mail.yahoo.com> (grgoffe@yahoo.com) |
| Received-SPF | softfail client-ip=2001:558:fe21:29:69:252:207:44; envelope-from=worley@alum.mit.edu; helo=resqmta-ch2-12v.sys.comcast.net |
| X-detected-operating-system | by eggs.gnu.org: First seen = 2020/08/25 22:10:15 |
| X-ACL-Warn | Detected OS = ??? |
| X-Spam_score_int | -11 |
| X-Spam_score | -1.2 |
| X-Spam_bar | - |
| X-Spam_report | (-1.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665 autolearn=no autolearn_force=no |
| 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 | <87o8mynonc.fsf@hobgoblin.ariadne.com> |
| Xref | csiph.com gnu.bash.bug:16815 |
Show key headers only | View raw
I was going to suggest this analysis, but George has gotten ahead of me, so let me collate the two: My understanding is that the details of how different programs read directories differs, and how different operating systems implement those operations differs, and how different file systems under an operating system implement them differs. But overall, reading large directories can take a long time, and often the operations involved are not interruptable. (At root, that is because this is an uncommon scenario in Unix and people don't work to optimize it.) So I was going to recommend this calibration: Go to the directory in question and execute "time ls -1 >/dev/null". That gives you the maximum amount of time it will take to read that directory, and that should be an upper bound on how long it will take bash to finish whatever completion operation it is doing. George R Goffe <grgoffe@yahoo.com> writes: > I found how how to make konsole do a visual alarm and then tried my > failure scenario. > > I cd'd to a "big" directory and then entered "ls -al abc<tab key>", > waited a few seconds then did a ctrl-c. As usual, a freeze happened. I > waited a while and then saw the visual alarm followed by the ctr-c. OK, so it looks like there is some long, uniterruptable operation happening as part of filename completion. How does the length of that freeze compare to "ls -1", as described above? > Somewhere between the request for filename completion and the > recognition of ctrl-c appears to be where the "bug" is located. > > I could try running strace during all of this. Would it help? My guess is that could reveal some particularly slow operating system call that is involved in implementing filename completion, but it would not indicate a way to improve it. Dale
Back to gnu.bash.bug | Previous | Next | Find similar | Unroll thread
Re: Is this a bug? worley@alum.mit.edu (Dale R. Worley) - 2020-08-25 22:09 -0400
csiph-web