On Friday 25 January 2013 12:36:23 Karel Zak wrote: > On Fri, Jan 25, 2013 at 12:02:01PM -0500, Mike Frysinger wrote: > > On Friday 25 January 2013 10:17:36 Karel Zak wrote: > > > On Sun, Jan 20, 2013 at 06:27:22PM -0500, Mike Frysinger wrote: > > > > we could tweak parse_argv() so that it checks for argv[0] == '.' in > > > > addition to argv[0] == '/'. but that wouldn't fix other relative > > > > paths like: $ fsck images/foo > > > > $ fsck foo > > > > > > Hmm... maybe add a hint to the fsck man page is the best solution :-) > > > > > > > should we treat all non-options as devices ? would that break > > > > anything ? > > > > > > I don't think it's a good idea. > > > > > > All unknown stuff is by default interpreted as filesystem specific > > > options (options for fsck.<type>) and it's pretty common that people > > > don't use "--" separator between fsck and fsck.<type> options. > > > > well, i didn't mean non-fsck options, but non-options. i.e. things that > > don't > > I understand.. > > > start with dashes. are there fscks which use non-options as something > > other than "file/device to check" ? > > fsck.ext4 -L bad_block_file /dev/sda1 > > or whatever... and note that we have no clue about all possible fsck > implementations (not all is public and open source..) i would highlight the man page says people are supposed to use -- to separate fsck-specific options from fsck-specific ones. as to your example here though, that shows that things are also broken. if you give an absolute path to the bad_block_file, then the auto-silencing of the root partition is run. compare: fsck -L bad_block_file fsck -L $PWD/bad_block_file the first will auto-append the root device while the latter will not for no apparent reason to the user -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
