Jan Stary:
> http://cvsweb.netbsd.org/bsdweb.cgi/src/sbin/dump/main.c.diff?r1=1.4&r2=1.5&f=h
> "Use getopt(3), with obsolete() from restore(8) for backward compatibility."
>
> So it's restore(8); I write "restore rf" myself.
> Is this it? Does that still need to be supported by dump(8)?
The same
Sure. That solves the immediate problem, provides people with a
strong hint to use options, and does no harm to the legacy option
behaviour which people used for half a century and will use for
the next half a century
Todd C. Miller wrote:
> On Thu, 02 Jun 2022 07:54:02 -0600, "Theo de Raad
On Thu, 02 Jun 2022 07:54:02 -0600, "Theo de Raadt" wrote:
> I'm fine with a / check, but it also needs documenting. While there can't
> we say at least one option must be supplied?
How about this?
- todd
Index: sbin/dump/dump.8
Todd C. Miller wrote:
> True, those would not be handled but isn't the most common usage
> to pass a fully-qualified path or a device name? The biggest problem
> I see is that this would not catch a disk uid being used but I don't
> think that is really fixable unless we check the string for a d
On Thu, 02 Jun 2022 07:43:15 -0600, "Theo de Raadt" wrote:
> Hmm, but consider these cases
>
> dump home
>
> or
>
> mkdir 0af
> dump 0af
>
> or
>
> cd /dev && dump rsd0a
True, those would not be handled but isn't the most common usage
to pass a fully-qualified path or a device name? The biggest
Todd C. Miller wrote:
> On Thu, 02 Jun 2022 14:36:16 +0200, Jan Stary wrote:
>
> > That results in the above. What obsolete options format
> > is this trying to accomodate? The manpage doesn't say -
> > the options it describes are perfectly getopt()-likable.
> > Looking at the CVS log, this was
Jan Stary wrote:
> On Jun 02 07:16:52, dera...@openbsd.org wrote:
> > Your diff completely breaks a majority of the ways people use it.
>
> Does that mean people mostly use
> the undocumented obsolete syntax
> that obsolete() keeps supported?
It means at least 1 person use that option code, whi
On Thu, 02 Jun 2022 14:36:16 +0200, Jan Stary wrote:
> That results in the above. What obsolete options format
> is this trying to accomodate? The manpage doesn't say -
> the options it describes are perfectly getopt()-likable.
> Looking at the CVS log, this was already "obsolete"
> in the origina
On Jun 02 07:16:52, dera...@openbsd.org wrote:
> Your diff completely breaks a majority of the ways people use it.
Does that mean people mostly use
the undocumented obsolete syntax
that obsolete() keeps supported?
> Jan Stary wrote:
>
> > # dump /home
Your diff completely breaks a majority of the ways people use it.
Jan Stary wrote:
> # dump /home
> dump: option requires an argument -- h
>
> # dump /music
> dump: option requires an argument -- s
>
> # dump /media
> dump: option requir
On Jun 02 14:36:16, h...@stare.cz wrote:
> # dump /home
> dump: option requires an argument -- h
>
> # dump /music
> dump: option requires an argument -- s
>
> # dump /media
> dump: option requires an argument -- d
>
> What? Before passing
# dump /home
dump: option requires an argument -- h
# dump /music
dump: option requires an argument -- s
# dump /media
dump: option requires an argument -- d
What? Before passing its options to getopt(),
dump's main() processes them with ob
12 matches
Mail list logo
