No one likes spam, but I also don't consider cordova-cli a tiny isolated tool for composable usage in the unix toolbox, and so it shouldn't be striving to meet those particular requirements. Pragmatically speaking I think cordova-cli should print small but useful bit of status information.
However, it would be desirable to have nothing printed when cordova is being consumed as a node module, and only do so when actually run from a console using the cordova binary directly. -Michal On Thu, Sep 5, 2013 at 3:14 PM, Carlos Santana <csantan...@gmail.com> wrote: > I would like to see by default some type of minimal high level progress > information, not crazy massive output like npm with warnings when stuff is > working > > - fetching files from [network, cached] > - adding files [platforms/ios] > - modifying file [plugins/ios.json] > - merging files [merges/ios] > - running hooks [..] > - running platform script [platforms/ios/bin/create] > > > Sometimes I think the cli is broken, because it doesn't return and no > output is given. and its a matter of waiting a while. or just wait for the > cli to fail > I feel like waiting for a surprise, surprise it finish run echo $? or > surprise you waited enough to see the failed message. > > > I agree log/verbose levels should be a good enhancement > > > > On Wed, Sep 4, 2013 at 9:08 PM, Andrew Grieve <agri...@chromium.org> > wrote: > > > I don't think your attachment worked. > > > > > > On Wed, Sep 4, 2013 at 5:03 PM, Brian LeRoux <b...@brian.io> wrote: > > > > > Composability being the big reasoning. Maybe that is a false > > consideration > > > for our end users. I know I hate chatty tools (and I hate telling them > to > > > be quiet) and that could just be a preference from java scars. > > > > > > Some very light reading attached from 'Classic Shell Scripting' > regarding > > > UNIX tools philosophy. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Sep 4, 2013 at 1:38 PM, Andrew Grieve <agri...@chromium.org > > >wrote: > > > > > >> cd and rm don't make network requests. There's plenty of precedent for > > >> outputting by default. zip, wget, rsync, apt-get, brew. > > >> > > >> You can always use --quiet if you pipe our command and have it not > > output. > > >> Am I missing something about your use-case? > > >> > > >> We have a practical problem right now in that we get a lot of bad bug > > >> reports where we need to tell users to re-run with --verbose. Almost > > every > > >> day in IRC, someone gets told to re-run with --verbose. > > >> > > >> > > >> On Wed, Sep 4, 2013 at 4:23 PM, Brian LeRoux <b...@brian.io> wrote: > > >> > > >> > Well, those aren't UNIX tools. Those are userland tools. (So are > we, I > > >> > know.) > > >> > > > >> > Imagine if `cd` output something every time you moved. Or rm was > > always > > >> > noisy. Super annoying. Anyhow, the book Classic Shell Scripting > > explains > > >> > this better than I. Recommended reading. > > >> > > > >> > I'd rather our tools followed UNIX philosophy here and where quiet > by > > >> > defaul and noisy if asked. For the record, I've talked to Issac > about > > >> just > > >> > this issue in node b/c it makes composing scripts more difficult > when > > >> you > > >> > have to pipe garbage output around and a tacit plan for npm was to > > make > > >> it > > >> > quiet by default someday when it gets stable. (Who knows if that is > > >> still > > >> > the case.) > > >> > > > >> > > > >> > On Wed, Sep 4, 2013 at 1:01 PM, Andrew Grieve <agri...@chromium.org > > > > >> > wrote: > > >> > > > >> > > I don't think that's really true for other similar tools. > > >> > > E.g. "npm install" reports progress by default > > >> > > E.g. "git clone" shows progress by default. > > >> > > > > >> > > > > >> > > On Wed, Sep 4, 2013 at 3:51 PM, Brian LeRoux <b...@brian.io> wrote: > > >> > > > > >> > > > The convention for UNIX tools is to be quiet by default and fail > > >> > > noisily. A > > >> > > > well writ script should exit quietly so you can chain commands. > > (Or > > >> > pipe, > > >> > > > etc.) > > >> > > > > > >> > > > I'd prefer we added a --verbose flag. > > >> > > > > > >> > > > > > >> > > > On Wed, Sep 4, 2013 at 12:35 PM, Braden Shepherdson < > > >> > bra...@chromium.org > > >> > > > >wrote: > > >> > > > > > >> > > > > I'd rather we call it -q and --quiet though; that's a pretty > > >> common > > >> > > > > convention for Unix tools. > > >> > > > > > > >> > > > > > > >> > > > > On Wed, Sep 4, 2013 at 3:35 PM, Braden Shepherdson < > > >> > > bra...@chromium.org > > >> > > > > >wrote: > > >> > > > > > > >> > > > > > +1 > > >> > > > > > > > >> > > > > > > > >> > > > > > On Wed, Sep 4, 2013 at 3:31 PM, Andrew Grieve < > > >> > agri...@chromium.org > > >> > > > > >wrote: > > >> > > > > > > > >> > > > > >> I think this was discussed before but I can't find the > > thread. > > >> > > > > >> > > >> > > > > >> Is anyone not in favour of making the tools verbose by > > default > > >> and > > >> > > > > having > > >> > > > > >> a > > >> > > > > >> --silent flag instead? > > >> > > > > >> > > >> > > > > >> Makes it much easier to get good debug reports and lets > users > > >> know > > >> > > > when > > >> > > > > >> slow things are taking place. > > >> > > > > >> > > >> > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > > > > > > > > > > > -- > Carlos Santana > <csantan...@gmail.com> >
