From: "Marek Behún" <marek.behun@nic.cz>
To: Stefan Roese <sr@denx.de>
Cc: "Pali Rohár" <pali@kernel.org>, "Tony Dinh" <mibodhi@gmail.com>,
"U-Boot Mailing List" <u-boot@lists.denx.de>
Subject: Re: kwboot - positional tty argument
Date: Mon, 7 Mar 2022 17:45:53 +0100 [thread overview]
Message-ID: <20220307174553.1a40c122@dellmb> (raw)
In-Reply-To: <e524d28e-7851-53ad-b0de-71a6632217b3@denx.de>
On Mon, 7 Mar 2022 15:39:33 +0100
Stefan Roese <sr@denx.de> wrote:
> On 3/7/22 12:40, Pali Rohár wrote:
> > Hello!
> >
> > On Sunday 06 March 2022 14:38:57 Tony Dinh wrote:
> >> Hi Pali,
> >>
> >> I have an observation, which is not related to this patch. But about
> >> the kwboot options changes in general, I hope it is OK to mention it
> >> here.
> >>
> >> Before the changes you've made to solve the problem with the -b
> >> option, I can do this:
> >>
> >> kwboot -t -B 115200 /dev/ttyUSB0 -b uboot.kwb
> >
> > Interesting... I did not know that this kind of setup worked. It was not
> > documented neither in usage nor in manpage. Normally in applications and
> > scripts, all option arguments are before non-option (positional)
> > argument.
> >
> >> But now, the -b option can not be used after the tty device name. All
> >> options must appear before the tty device.
> >>
> >> Is this the actual intention? it did break some of my existing
> >> aliases/scripts (It is not a big deal to retrofit them). Just want to
> >> make sure I understand the reason to make the tty device a positional
> >> argument for kwboot.
> >>
> >> Thanks,
> >> Tony
> >
> > Marek, Stefan, do you want to support above (old) handling of positional
> > tty device argument to be present in the middle of option arguments?
>
> I personally don't...
>
> > I think I can develop some "hack" patch for argv[] processing to support
> > this operation. But my question is, if this is something which we want
> > to officially support. Because if not, it is better to have separate
> > option arguments and positional arguments like in any other application.
>
> ...
>
> The only case I can think of, is scripts that use the "incorrect" format
> and might fail now. I don't have any such scripts and I would not object
> to breaking this backward compatibility. Tony, what's your thinking on
> this? Marek?
I don't care. I only care whether I can use the -t flag after
everything else, and I think this still works.
Marek
next prev parent reply other threads:[~2022-03-07 16:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-06 12:39 [PATCH] tools: kwboot: Check if baudrate value is supported before sending image Pali Rohár
2022-03-06 13:12 ` Marek Behún
2022-03-06 22:38 ` Tony Dinh
2022-03-07 11:40 ` kwboot - positional tty argument Pali Rohár
2022-03-07 14:39 ` Stefan Roese
2022-03-07 16:45 ` Marek Behún [this message]
2022-03-07 17:41 ` Pali Rohár
2022-03-08 6:15 ` Tony Dinh
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=20220307174553.1a40c122@dellmb \
--to=marek.behun@nic.cz \
--cc=mibodhi@gmail.com \
--cc=pali@kernel.org \
--cc=sr@denx.de \
--cc=u-boot@lists.denx.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.