I am not sure how the extraction process is occurring, but have you taken a look at 7za. The command line interface is ugly, but it supports compression and uncompression of multiple formats So one wouldn't necessarily have to run file foo, determine the type and run unzip. 7za x <foo> will do it for you. Here's an example. I gzipped TOI.odp and then renamed the file to TOI.odu.
> 7-Zip (A) 4.55 beta Copyright (c) 1999-2007 Igor Pavlov 2007-09-05 > p7zip Version 4.55 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs) > > Listing archive: /tmp/TOI.odu > > ---------- > Path = TOI.odp > Size = 758931 > Packed Size = 693105 > Modified = 2008-05-06 17:31:28 > Host OS = Unix > CRC = 0AFA1584 > and now extracting > 7za x /tmp/TOI.odu > > 7-Zip (A) 4.55 beta Copyright (c) 1999-2007 Igor Pavlov 2007-09-05 > p7zip Version 4.55 (locale=en_US.UTF-8,Utf16=on,HugeFiles=on,2 CPUs) > > Processing archive: /tmp/TOI.odu > > Extracting TOI.odp > > Everything is Ok > > > Total: > Folders: 0 > Files: 1 > Size: 758931 > Compressed: 693131 Jack Schwartz wrote: > Attendees: Sundar, Frank, Bill, Zhong-Yuan, Li-Yan, Tony > Host: Jack > > === General technical discussion: > > How to do SVR4 package install noninteractively? > Use of admin file. Referred to a DistroConstructor webpage > which gave an example of how to set one up for non-interactive > pkgadd. > > Script to auto-download a file from 3rd party and unzip the file. > The "file" command is used to identify the file first. > > Bill found one type of zip file which can be unzipped using the > "zip" command, but is not recognized by the "file" cmd. > > He wants to add another entry to the /etc/magic file so that > type of zip file is recognized by the "file" command. > > Jack to find out who modified /etc/magic last and tell China > team. > > Changes to /etc/magic may need to be ARCed. Jack to send them > info about this. > > Tony pointed out there are three possible states a driver can be in > as far as the DDU is concerned: > - Driver missing > - Driver installed but not launched (attached) > - Driver launched (attached) > > Once the "add_drv -n" issue is fixed there shouldn't be a case > where a driver is installed but not attached, as the GUI > doesn't provide a way to do an update (replacement of an > active driver with another). > > Still, it is a good idea to handle the situation of a driver > end up being installed but not attached by displaying > accurate status. > > === Discuss networking config in text-mode DDU > > We're not going to do it. > > System will be configured with NWAM and if the lab has DHCP running, > the system will have networking enabled. Otherwise, drivers can be > added from local media. > > The ddu will have to deal with the situation of no network, if no > network exists. > > Discussion about whether or not installing from a repo should be > disabled if no network exists. Answer: No, since repos can be on > local media. > > === Discuss package name in ddu_package_object > > Should the package name be included in the ddu_package_object? > > Jack noted that adding the name was not helpful for searching, as the > search would be over by the time the object is created. > > However, there were other reasons for adding the name: > > - driver name is helpful for displaying after a successful > install. > > - There are some 3rd party webpages containing lots of drivers. > Adding the name field to the ddu_package_object would help > locate the right driver in that page. > > - Jack to add this to the spec. > > === Discuss writing out package list from GUI and text-mode DDU > > - This came up to satisfy a possible future need. We decided > it would be a bad idea to do this since we don't now know > exactly what would be needed and in what form. Best to > implement it when it is needed. > > - Resolved that the DDU team will keep in mind while they code, > that this may be needed for the future, and to leave a hook > for it if appropriate. > > === Frank and UI issues (added) > > 2 items: > > 1) Frank sent email just before meeting, of what the text mode DDU > would look like with ncurses. > > He also proposed two other approaches: > > - console based interaction, similar to current ITU. > This would be a command which prompts for info (a > subcommand), accepts the subcommand and args, executes it, > displays any result, then prompts for another subcommand. > This is more like what S10 has currently. > > - A CLI. "dduadm" with subcommands like "list", "install". > > Frank to send out a more detailed description tomorrow. > > 2) GUI screen organization > > Frank and Zhong-Yuan designed a GUI screen for DDU. It would be posted > from the notification window button. (Notification window is what runs > in background when the system comes up.) This screen is similar but > not the same to the screen for add-drivers mode. (The former doesn't do > an install of a single driver.) > > Frank proposed having both the notification window button and the DDU > icon go to the same add-drivers mode screen. > > Frank to send out proposal tomorrow with more meat in it. He will > integrate new functionality and layout into current (i.e. old) DDU > screen. > > > On 09/08/09 10:49, Jack Schwartz wrote: >> Hi everyone. >> >> The Driver Update team will hold a meeting this week. >> >> Logistics: >> Thursday 9/10 8AM PRC time >> Wednesday 9/9 5 PM PST, 6 PM MT >> Call number: 866-545-5227 >> International: 215-446-3648 >> Passcode: 7385082 >> >> Agenda: >> Status >> Discuss networking config in text-mode DDU >> Discuss package name in ddu_package_object >> Discuss writing out package list from GUI and text-mode DDU >> Questions and Answers >> >> Thanks, >> Jack >> > > _______________________________________________ > caiman-discuss mailing list > caiman-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
