> "BV" == Bernhard Voelker writes:
BV> Well, there are many possibilities, but there is already a way to
BV> to do it in xargs. So what would you want to achieve by saving a RET?
BV> I don't think it's about the wearing of the ENTER key on your keyboard?
Thank you. If there is a way to do
$
On 04/10/2016 03:52 PM, 積丹尼 Dan Jacobson wrote:
> BV> Without RET, this would all be mangled and the commands would be
> BV> unreadable on a terminal.
>
> All I know is there could be an additional option added to switch it
> into a mutt mail reader like mode just before waiting for each response,
BV> Without RET, this would all be mangled and the commands would be
BV> unreadable on a terminal.
All I know is there could be an additional option added to switch it
into a mutt mail reader like mode just before waiting for each response,
wherein one character is read without waiting for a RET.
On 04/10/2016 03:12 PM, 積丹尼 Dan Jacobson wrote:
> Wait, how about an option to eliminate the need for RET:
>
> so now all they would need to type is
>
> RET y RET RET y y
> or even
> x y x x y y
> or any non y ...
> wait, how about just n,y,and q(to quit), and maybe "." to d
On 04/08/2016 03:15 PM, Young Mo Kang wrote:
> On 04/06/2016 07:33 PM, Bernhard Voelker wrote:
>> Sorry for the late reply.
>> I thought a bit about the implementation and thought it'd be better
>> to avoid artificially creating the OR-ed predicates, and rather store
>> the wanted file types in an
> "BV" == Bernhard Voelker writes:
BV> Although you're maybe right from the logical point of view, I'm not
BV> sure if 'xargs -p' is used often enough to warrant adding such an option
BV> to the code. The next user may then come and want to have yet another
BV> option like --interactive-assu
On 04/08/2016 03:52 PM, 積丹尼 Dan Jacobson wrote:
> xargs has
>
>-p, --interactive
> Prompt the user about whether to run each command line and read
> a line from the terminal. Only run the command line if the re-
> sponse starts with `y' or `Y'.
On 04/01/2016 11:56 AM, Orivej Desh wrote:
> I would like xargs to attempt to terminate its children when one of them
> returns with the code 255 to stop immediately, whereas currently xargs
> imposes unnecessary delay and, when process produce output, makes the
> output of a failing process to be
