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>
References: <145044955.7635963.1598401276773@mail.yahoo.com> (grgoffe@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

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