Something I may not have expressed adequately... I strongly believe that
full backward compatibility should be maintained. I'm sure I'm not the only
person who doesn't want to change all their scripts. And "full backward
compatibility" means that any command line that would have worked in the old
version should work the same way in the new (as much as feasible).
I also strongly believe that the current behaviour is completely
non-intuitive and frustrating and should be fixed. Therefore my proposal.
-Mark Bartel
-----Original Message-----
From: Mark Bartel <[EMAIL PROTECTED]>
Sent: Wed, 15 Nov 2000 10:53:59
To: [EMAIL PROTECTED],[EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: mkisofs interface
I had to do considerable experimentation to get mkisofs do what I thought it
should. I kept expecting it to behave like other unix utilities such as
tar, cp, ln, mv, etc. Eventually I figured out what it was doing. In my
case your fix would not be compatible (I specify more that one directory).
My proposal: create a new option (I believe that -O is not already used)
that is the same as the -o option except causes the parameters to be used
the same as tar, which seems fairly intuitive to me. Old scripts would
still work, but people wanting intuitive behaviour can use -O. So
mkisofs -O /tmp/xxx dir/
would put the directory dir in the root,
mkisofs -o /tmp/xxx dir/
would behave as it always has, putting the contents of dir in the root.
The documentation can deprecate -o in favour of -O.
I think it'll just make things worse try to "guess" where backward
compatibility is needed. The -o versus -O would make it explicit. The "how
many directories do I have" technique would provide a whole new area for
confusion.
-Mark Bartel
-----Original Message-----
From: [EMAIL PROTECTED]
Sent: Wed, 15 Nov 2000 15:59:05 +0100 (MET)
To: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED],
[EMAIL PROTECTED]
Subject: Re: mkisofs interface
>From: [EMAIL PROTECTED] (Bill Davidsen)
>> Sorry, my mail seems to be non-obvious:
>>
>> What should happen with:
>>
>> mkisofs -o /tmp/xxx dir/
>> mkisofs -o /tmp/xxx file
>> mkisofs -o /tmp/xxx dir1/ dir2/ file ....
> In this case I believe that what I would expect to happen (as an
>experienced user), what I would like to happen, and what the user
>entering these commands might mean are at least two different things.
>> mkisofs -o /tmp/xxx dir/
>I would expect this to use the contents of dir/ as the base for the ISO
>image, so file dir/foo would be foo on the CD. And in this case I think
>most users would want that.
>> mkisofs -o /tmp/xxx file
>I would expect a very small ISO image with a single file.
>> mkisofs -o /tmp/xxx dir1/ dir2/ file ....
>I would expect dir1 and dir2 contents to be "lowered" by one level, as
>in the first case. I suspect that most people would assume that dir1 and
>dir2 would be preserved, but after writing scripts to generate
>dir1/=dir1 over and over, I have learned what this does.
>Comments:
>1. The current behaviour is consistant. I don't like it, it's
>unintuitive, it gets really ugly when you want to preserve a bunch of
>directories, but it works.
My intention was to make it behave this way:
mkisofs -o /tmp/xxx dir/
Will use dir/ as root dir for the CD
mkisofs -o /tmp/xxx file
Will have only file in the root dir of the CD
mkisofs -o /tmp/xxx dir1/ dir2/ file ....
Will have dir1/ dir2/ and file in the root dir of the CD
mkisofs -o /tmp/xxx ab/cd/ef/dir1/ hello/dir2/ file ....
Will have dir1/ dir2/ and file in the root dir of the CD
I hope that this is intuitive.
>2. As nice as a short form would be, I think having "dir1" "dir1/" and
>"dir1/." not do the same thing would confuse the hell out of the typical
>users.
Right. First: POSIX requires dir and dir/ to be the same.
>3. I'm attracted to having an option which is followed by a list of
>directory names, which would appear on the CD unchanged.
>as: cdrecord -o foo -dirlist abc,def/,/usr/local/src
>same as: abc/=abc def/=def usr/local/src/=/usr/local/src
I believe that this is not simple enough.
Keep in mind that even the current dir=dir syntax is not understood
by all users and that my REMOTE SCSI seems not to be accepted because
most people don't understand the possible usage.
>4. I would love to make the general case of xxx=yyy mean that file or
>directory yyy would appear as xxx on the CD. It would mean that any
>name which contained an equal would be a special case. That actually
>does affect me, but names with equal are unusual, and I certainly would
>rather have the usual case be easy and intuitive. I really need equals
>in both disk and CD names, but I don't mind inconvenience as a penalty
>for having to support an ill-designed application.
How about my proposal:
Use the old behavior only if there is only one dir type arg.
If there is a file type arg or if there are more args, then
make the last path component appear on the root dir of the CD.
Jörg
EMail:[EMAIL PROTECTED] (home) Jörg Schilling D-13353 Berlin
[EMAIL PROTECTED] (uni) If you don't have iso-8859-1
[EMAIL PROTECTED] (work) chars I am J"org Schilling
URL: http://www.fokus.gmd.de/usr/schilling ftp://ftp.fokus.gmd.de/pub/unix
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
