Hi Efraim,
On Thu, 14 May 2020 at 10:15, Efraim Flashner wrote:
> $ guix package -p profile1 -p profile2 -I | wc -l
> 91
> $ guix package -p profile2 -p profile1 -I | wc -l
> 12
I bet:
$ guix package -p profile1 -I | wc -l
91
$ guix package -p profile2 -I | wc -l
12
Well, thank you for the re
Dear Arne,
On Wed, 13 May 2020 at 20:53, Arne Babenhauserheide wrote:
> zimoun writes:
> > It would like it works. And to do so, I accept that "guix package -I
> > regexp -p /tmp/profile" does not anymore and would be replaced by
> > "guix package -Iregexp -p /tmp/profile" which already works
On Fri, Apr 24, 2020 at 10:28:50AM +0200, zimoun wrote:
> On Thu, 23 Apr 2020 at 21:52, Tom via Bug reports for GNU Guix
> wrote:
> >
> > To add detail here:
> >
> > Doing `guix package -d 18 -S 17` actually works.
> >
> > This gives me the impression that the order of arguments is relevant to the
Dear zimoun,
zimoun writes:
> It would like it works. And to do so, I accept that "guix package -I
> regexp -p /tmp/profile" does not anymore and would be replaced by
> "guix package -Iregexp -p /tmp/profile" which already works (as
> specified by SRFI-37).
Wow, this surprised me. I expected
Dear Arne,
On Wed, 13 May 2020 at 18:32, Arne Babenhauserheide wrote:
> And please don’t do radical changes on guix package. That would break
> the workflow of every slightly longer term guix user.
I do not want to do radical changes. The parser of the command-line
is SRFI-37. So it is docume
Tom Zander via Bug reports for GNU Guix writes:
>> > You asked for an example; see `git commit -S`. From the manpage:
>> >-S[], --gpg-sign[=]
>>
>> Thank you for the example. Let me show you that it raises an issue
>> too because it is not so "simple". :-)
>
> Easier example then: from t
It looks like I was wrong on the ls example,
more importantly, it seems we all agree that short options with optional
arguments are messy, at best.
I think the best course of action is to take a look at the guix command line
design and find a way to move away from depending on them. Maybe some
On Tue, 12 May 2020 at 22:19, Tom Zander wrote:
> They are expected to always be equivalent. It would not be logical to have the
> short one as an alias if they are not equivalent.
I agree.
Note that you cannot have short-name with optional argument or you
have to break a rule; see below.
> >
On dinsdag 12 mei 2020 20:08:32 CEST zimoun wrote:
> > The design of the short options is that it is an alias. Identical to the
> > software regardless of what the user typed.
>
> Yes. But AFAIU, it is hard -- not impossible -- to detect what is an
> argument or what is another option in the case
Dear Tom,
On Tue, 12 May 2020 at 18:23, Tom Zander wrote:
> The other is the ordering of arguments being parsed unpredictable.
> The usecase given was the `-d 1 -S 2` arguments (see earlier emails for
> details).
Fix for that coming soon. :-)
Thank you for the report.
> > Please could you i
On dinsdag 12 mei 2020 13:35:04 CEST zimoun wrote:
> On Tue, 12 May 2020 at 11:55, Tom Zander via Bug reports for GNU Guix
>
> wrote:
> > the bugreport is a usability bug which stems from the fact that the
> > command
> > line parser behaves differently from every single other commandline parser
Dear Tom,
On Tue, 12 May 2020 at 11:55, Tom Zander via Bug reports for GNU Guix
wrote:
[...]
> C apps using libc, python apps using their parser, even C++ apps using the Qt
> commandline classes, all are generally compatible with regards to behavior.
>
> Only Guix is different.
Please could yo
On Tue, 12 May 2020 at 10:51, Ludovic Courtès wrote:
> Nothing new here, and everything is properly documented.
Using optional argument with short-option names is unusual, AFAIK.
And for sure, there is an ambiguity; as we are seeing here. :-)
However, the only mention of that is in the commentar
On Tue, 12 May 2020 at 11:55, Tom Zander via Bug reports for GNU Guix
wrote:
> the bugreport is a usability bug which stems from the fact that the command
> line parser behaves differently from every single other commandline parser
> average people like me have ever used.
>
> A near 100% of the c
Hi Ludo,
Sorry, I am not compliant and reorder your quotes to ease the
discussion -- from my point of view. :-)
On Tue, 12 May 2020 at 10:51, Ludovic Courtès wrote:
> However (srfi srfi-37) does it as we see it now. Fixing it would mean
> implementing a different option parser.
Yes or add a
On dinsdag 12 mei 2020 10:51:28 CEST Ludovic Courtès wrote:
> Nothing new here, and everything is properly documented.
The bugreport was not about a disconnect between documentation and the tool,
the bugreport is a usability bug which stems from the fact that the command
line parser behaves diff
Hi,
zimoun skribis:
>> --8<---cut here---start->8---> # OK
>> guix package --list-generations -p /path/to/profile
>> guix package --list-installed -p /path/to/profile
>>
>> # KO
>> guix package -l -p /path/to/profile
>> guix package -I -p /path/to/profile
TLDR: there is no "real" bug. :-)
Just a choice to do and document it.
On Fri, 24 Apr 2020 at 10:28, zimoun wrote:
> guix package -I -A # does nothing
> guix package -A -I # list available
Expected.
First line, -I -A' means that '-A' is seen as an argument for '-I'.
Idem for the second li
On Thu, 23 Apr 2020 at 21:52, Tom via Bug reports for GNU Guix
wrote:
>
> To add detail here:
>
> Doing `guix package -d 18 -S 17` actually works.
>
> This gives me the impression that the order of arguments is relevant to the
> processing of them.
It is known and cumbersome: a feature? ;-)
Othe
To add detail here:
Doing `guix package -d 18 -S 17` actually works.
This gives me the impression that the order of arguments is relevant to the
processing of them.
This sounds like a bad idea because that is quite unlike the normal gnu
command line parsers behavior (and generally any command l
20 matches
Mail list logo
