Util-Linux package development
 help / color / mirror / Atom feed
From: Rick van Rein <rick@openfortress.nl>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org
Subject: Re: PATCH: script: Introduced a streaming output command
Date: Mon, 10 Dec 2018 13:47:19 +0100	[thread overview]
Message-ID: <5C0E6057.5010309@openfortress.nl> (raw)
In-Reply-To: <20181210114634.ee5jamwllimdmrdc@ws.net.home>

Hello Karel,

Thanks for the evaluation.  I will follow your hints on all points, some
are subjective but these are your prerogative.  New patch will come in a
few days.

> Nice idea ;-)

Thanks.  I didn't want to mention a specific online service in the
"real" documentation, but the idea was inspired by "nc seashells.io 1337".

> Do we really need the default command? ;-) 

No, it's merely a luxoury.  One might say that something _around_ script
is another way of doing this.  I will remove it.

> I think the example with nc(1) in the man page is good enough. We do
> not need hardcode any path/name in the code.

OK.  This a matter of taste, I will follow your directions.

> It would be better to use one bit for this boolean,
> 
>   unsigned int
>     stream :1

Yes I agree.  I hadn't noticed that :1 was used on other flags (they're
concentrated below, I see now).  Will change move it into that habit.

>     if (ctl->stream)
>         wait_for_stream_cmd(ctl, 0);
> 
> I guess it would be more robust, than call wait_for_stream_cmd()
> in all situations.


OK, will do.

>> +	int cmdio[2];
> 
> It's detail, but stream_pipe[] wold be more readable :-)

Sure, will do.

>> +			fprintf(stderr,_("streaming command failed: %s\r\n"),strerror(errno));
>> +			exit(1);
> 
>     err(1, _("streaming command failed"));
> 
> err() seems better than fprintf() + strerror() + exit();

I missed that option.  Will do.

> Frankly, all the command-line semantic seems complicated and a little
> bit like over-engineering.

I am trying to make it simple to use, with a minimum of entry (and
manpage reading).  It's a matter of taste, and falls in the same line as
moving the default script from inner command to wrapper around script.
So I'm not going to debate this, and follow your taste.  It's your
software, after all :)


I will post a new patch in a while (and this time I'll be more accurate
about the subject and line breaks while logically occurred in the email
body).

  reply	other threads:[~2018-12-10 12:47 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-06 11:43 PATCH: script: Introduced a streaming output command Rick van Rein
2018-12-10 11:46 ` Karel Zak
2018-12-10 12:47   ` Rick van Rein [this message]
2018-12-10 14:47   ` Rick van Rein
2018-12-17  9:43     ` Karel Zak

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5C0E6057.5010309@openfortress.nl \
    --to=rick@openfortress.nl \
    --cc=kzak@redhat.com \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox