Conference hydra::amiga_v1

    I have not been able to extract the doc files from FF346 with LHARC.
    Parhaps someone can tell me what I'm doing wrong or if there is
    a bug/limitation in the VMS version of LHARC.
    
    LHARC x FF346 Az/AZ_English/Manual/*
    
    Returns: No files extracted.
    
    LHARC l FF346 works OK.
    
    Regards
    Peter

    
    In support of previous note:
    
    I had trouble with LHARC (Version X1.00 on the Vax).  I was able to
    extract an entire archive with no problem but couldn't find a syntax
    that allowed me to get out a sub-set.   I thought "maybe this feature
    is not implemented in the VMS version".  
    
    Any help greatly appreciated.
    
    Frank
    

    You can extract files individually:
    
    	LHARC x FF346 Az/AZ_English/Manual/ReadMeFirst
    
    But there doesn't appear to be any wildcard support.

    There is a newer version of LHARC.EXE in CGOU01::AMNEW: I actually
    stuck it there a while back. It supports VMS wildcarding for adding
    to an archive but NOT YET for extracting. Unfortunately it is not just
    a matter of converting these features (ie wild cards etc..) but
    actually adding them from scratch. Since this unix version of LHARC 
    that I ported did not have any wild card support at all.
    
    I will get to it in the next little while.
    
    For now you have to extract by file name by specifying the full path
    (not case sensitive) or the whole archive. You can prevent LHARC from
    creating directories and force it to place the extracted file in the
    current directory by specifying the 'i' switch. For example:
    
    	$ LHARC xi ff343.lzh /project1/source/readme
    
    will place the file readme in your current directory. You could also
    specify the 'p' option which just prints the file to your terminal
    without creating any files.
    
       The vms wild card support for adding to archives is specified as
    
        $ LHARC a newarchive [DREW.SUBDIR1...]*.* [DREW.SUBDIR2...]*.c
    
    more later 
    
    	/Steve.
    
    
    

    Given the current limitations of LHARC is it not a bit premature
    to use it instead of ZOO for FISH disks?  Currently the only thing
    on the plus side is a few disk blocks.
    
    Peter

    
    Anything that cuts down time on uploads is of value, after all this
    last batch required over 6 hours to upload.
    
    The current state if lharc makes it usable even without wildcards,
    because the user can still explicitly extract a file or can extract the
    whole works and then delete those not desired with the VMS wildcard
    (after all its only 1700 disk blocks) for the entire disk.
    
    So unless somebody else volunteers to provide the Fish disk in whatever
    format they like, I shall continue with LHARC.
    
    wayne
    

    Re: .4
    
    Well, I at least have never gotten VMS-LHARC and wildcarding to work.
    All I get when I try it is something like this (Gee, I love VLT):
    
$ lh a test bzoevfl:[balzer.temp...]*.exe
LHARC bzoevfl:[balzer.temp...]*.exe: non-translatable vms error code: 0x18744, ms message:
%rms-f-wld, invalid wildcard operation
$
    
    Any ideas, Steve? Our cluster runs VMS 5.3.
    
    Regards,
    
    <CB>
    

    re:.6
     
    Steve,
     
    I agree completely, continue with LHARC, it saves time downloading as
    well!
     
    JK
    

    
    
    Maybe we should LHARC the ZOO ... eg
    Lharc a FF350.LZH FF350.ZOO
    
    would this be two much a pain for non-hard drive users???
    
    
    Shaun.
    

    
    RE: -1
    
    I think you will find that running LHARC on a ZOO archive will only
    produce and archive, 20 - 30 blocks smaller that the original ZOO
    archive. However using LHARC to to archive all the files, will produce
    an archive 150+ blocks smaller than the ZOO archive. I don't think the
    extra step would be  worth the effort.