Re: extfs cleanup

[Pavel Roskin <proski gnu org>]

Hello!

> Hi. I've spend some more time examining and testing extfs scripts,
> because I feel a lot more confortable with simple scripts than with
> complicated mc code :)

I understand.  It's good approach to learn mc by doing simple things
first.

> My results can be found in the attachment. If you have any comments,
> feel free to mail me. I'll try to update this list when something gets
> fixed.

It's a great job.  mc needs more testing.

> I think broken scripts could be fixed until next stable release, and I'm
> willing to spend my time to work on the issues I've found.

I agree.

> Pavel, could you review my uzoo and urar fixes (earlier in this thread),
> please? Tell me which modifications you think are useful, and which are
> not, so I won't waste my time on things you don't like.

With the recent surge in the mailing list traffic it's hard for me to
review everything that gets posted, but I'll try.

The big problem is that there is no portable "which" command.  "type" is
bash-specific.  It's not a theoretical limitation.  When I used "which" is
a script for Automake CVS, I got a complaint almost immediately from
somebody who actually needed to run that script and actually didn't have
"which".  Yet the script was meant only for developers using CVS!

Scanning the PATH in the shell is the only working approach, but it can be
slow.  Don't forget, mc is still used on embedded systems, sometimes with
i386 processors.

Maybe the right solution would be to have a script that would actualize
the paths on the system where mc is installed.  The parameters would be
written by the script to some file (e.g. .mc/extfs) and then loaded into
the environment by mc.  It's just one of possible solutions, but I don't
see any simple approach that would be safe to use before the release.

Using filenames without path should be fine in some cases (i.e. unzip).  
On the the other hand, it's quite possible to have a system without awk,
but with nawk, mawk and gawk.  Even in the case of unzip, zipinfo support
should be tested.

I would prefer if you don't use names like "Copyin" in the output.  Users
of mc don't know what "Copyin" means - they want to add a file to the
archive.  The translation file mc.pot was full of such terms as "error
mkdir'ing" and "cannot cd".  I think the translators were cursing whoever
wrote all that in user-visible strings.

Don't forget that if the archiver fails, it outputs it's own diagnostics
on stderr.  It may be sufficient in many cases.  In fact, if it's not
sufficient, it's better to fix the archiver, not mc.

I don't like having any debug code in the scripts.  My experience shows
that the debugging stuff left by other people is almost always useless for
me, and I can always write something more suitable for me.

The only change I can accept is checking the status of some commands and
exiting.  In some cases, adding "set -e" in the beginning should be
enough.

I think the really important change would be to capture stdout and stderr
for all commands using redirection instead of relying on the scripts.  
Again, it may be quite intrusive to do it before the release.

-- 
Regards,
Pavel Roskin