[Top] [All Lists]

Re: [PATCH] xfsdump: handle Ctrl-D during prompts

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: [PATCH] xfsdump: handle Ctrl-D during prompts
From: Bill Kendall <wkendall@xxxxxxx>
Date: Thu, 10 Nov 2011 10:39:42 -0600
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20111110083113.GA10573@xxxxxxxxxxxxx>
References: <1320876946-27643-1-git-send-email-wkendall@xxxxxxx> <20111110083113.GA10573@xxxxxxxxxxxxx>
User-agent: Thunderbird (X11/20080502)
Christoph Hellwig wrote:
On Wed, Nov 09, 2011 at 04:15:46PM -0600, Bill Kendall wrote:
xfsdump does not currently handle Ctrl-D well during a dialog
prompt. If some text is entered followed by Ctrl-D, an assert
will trip because xfsdump expects a new-line character at the
end of the user's input (or if asserts are disabled, the last
character the user entered will be dropped).

If Ctrl-D is entered without entering any response, some dialog
callers (e.g., tree_subtree_inter()) will abort because they
receive an unexpected response code.

This patch changes xfsdump to treat Ctrl-D as if the user hit
enter. User input (if any) will be passed back to the caller,
and a new line will be echoed to the terminal.

Shouldn't Ctrl+D cause us to ignore the input that was added
before?  That's what I would expect from command line applications.

Ctrl-C will behave the way you describe.

I tried a some interactive programs (parted, python, sftp, bash,
xfs_db), and Ctrl-D seems to be ignored if there's already some input.
I'll rework the patch to behave this way unless I hear back from


<Prev in Thread] Current Thread [Next in Thread>