CantStopClicking Posted March 25, 2014 Share Posted March 25, 2014 Does anyone know if there is a command line version (PC, Mac, or Linux) to get file listings out of disk images? As well as ARC files? I'd like to be able to catalog all my disk images and output to a text file so I can do searches more effectively. Is there tool that already exists for this? I did a little searching but can't seem to find the answer. Cataloging by hand just isn't feasible on thousands of DSK images and would like to automate that if at all possible. TIA! -Dano Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 25, 2014 Share Posted March 25, 2014 Sigh ... my TIImageTool *had* that feature some releases ago, but I pulled it out because it seemed to have become obsolete. Maybe I can put it back in. There were two commands - "dir" produces a full listing, and "ls" only delivered the file names. (You know Unix-like systems, I suppose.) Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted March 25, 2014 Author Share Posted March 25, 2014 Sigh ... my TIImageTool *had* that feature some releases ago, but I pulled it out because it seemed to have become obsolete. Maybe I can put it back in. There were two commands - "dir" produces a full listing, and "ls" only delivered the file names. (You know Unix-like systems, I suppose.) Ok, cool, yeah that would be great to have. Searching my computer is a simple task but since my Mac doesn't know about DSK image format, those won't get indexed with the right metadata. So, having a command line tool that I can do a batch run would be awesome, then the text file will inherently get indexed and added to my search results. And yes, unix-like approach is welcome! Do you know what version might have had that? I think I've saved each version separately so I may have it already. I would love to create Mac 'Quick-Look' plug-in to add TI DSK image and ARChive file formats to native OS file operations but, that's asking for a lot right now. Thanks for the reply! -Dano Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 25, 2014 Share Posted March 25, 2014 (edited) Get the latest update (1.55) from WHTech ("PC utilities") or http://www.ninerpedia.org/index.php/TIImageTool You can invoke the command interpreter by passing the argument "CommandShell" to TIImageTool in the shell: $ java -jar dist/lib/tiimagetool.jar CommandShell dir ~/mess/disks/geneve/gdisk01.dsk SUBDIR (as an example; use your paths appropriately). Instead of "dir", you can also use "-h" (help text) or "ls" or "lsf". You can pass a final argument as subdirectory name. Check whether it suits your needs. Edited March 25, 2014 by mizapf Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted March 26, 2014 Author Share Posted March 26, 2014 Instead of "dir", you can also use "-h" (help text) or "ls" or "lsf". You can pass a final argument as subdirectory name. Check whether it suits your needs. I'm not sure I fully understand the SUBDIR piece? Didn't seem to like anything I used as an argument. Regardless, excluding the use of the SUBDIR portion, I gave it a shot from the command line and it seems to do the trick. So, next I created a quick shell script as follows: #!/bin/sh for FILE in *.dsk do java -jar '/Users/Dan/TI Stuff/TI_Disks/TIImageTool/tiimagetool.jar' CommandShell dir $FILE done Here's an example output: Calculon:tmp Dan$ ./test2.sh Volume in DSK1 is VDM99 Directory of DSK1 Filename Size Type Length P F Created Updated ------------------------------------------------------------------------------- !VDM99_V2 1 Dis/Var 80 2011-12-01 15:22:32 2011-12-01 15:22:32 ARC3 32 Program 8192 HOOKPIO1 2 Program 438 2011-12-01 15:10:48 2011-12-01 15:10:48 HOOKPIO1_O 6 Dis/Fix 80 2011-12-01 15:10:28 2011-12-01 15:10:28 HOOKPIO1_S 66 Dis/Var 80 2011-12-01 15:14:54 2011-12-01 15:18:20 HOOKPIO2 2 Program 438 2011-12-01 15:11:42 2011-12-01 15:11:42 HOOKPIO2_O 6 Dis/Fix 80 2011-12-01 15:11:24 2011-12-01 15:11:24 HOOKRS1 2 Program 452 2011-12-01 14:53:06 2011-12-01 14:53:06 HOOKRS1384 4 Dis/Fix 80 HOOKRS1HI 4 Dis/Fix 80 HOOKRS1_O 6 Dis/Fix 80 2011-12-01 14:52:08 2011-12-01 14:52:08 HOOKRS1_S 87 Dis/Var 80 F 2012-08-30 11:23:52 2012-08-30 11:23:52 HOOKRS2 2 Program 452 2011-12-01 14:58:02 2011-12-01 15:00:32 HOOKRS2_O 6 Dis/Fix 80 2011-12-01 14:57:10 2011-12-01 15:00:10 HOOKRS3 2 Program 452 2011-12-01 15:03:36 2011-12-01 15:03:36 HOOKRS3_O 6 Dis/Fix 80 2011-12-01 15:03:16 2011-12-01 15:03:16 HOOKRS4 2 Program 452 2011-12-01 14:59:14 2011-12-01 14:59:14 HOOKRS4_O 6 Dis/Fix 80 2011-12-01 14:58:44 2011-12-01 14:58:44 242 sectors in 18 files, 18 sectors not in this directory, 98 sectors free Calculon:tmp Dan$ Seems to work pretty good! The only thing I can see that might be an issue is.... speed. (I know I know, "now you want more!?!?") Takes about 3 seconds to get tiimagetool.jar to launch, dir listing, and have output. Multiply that by thousands of files and I'm thinking it will be quite a while before I see all results. Is it possible to stay in the CommandShell (within Java) and not exit to hammer away at all those disk images? The launching of java is what seems to take the longest. Either way, I'm happy with something!!! Yay! Thank you! -Dano Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted March 26, 2014 Share Posted March 26, 2014 v9t9 comes with command line tools to view dsk image catalog for dos/windows http://ftp.whtech.com/emulators/v9t9/600v9t9.zip Greg Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted March 26, 2014 Author Share Posted March 26, 2014 v9t9 comes with command line tools to view dsk image catalog for dos/windows http://ftp.whtech.com/emulators/v9t9/600v9t9.zip Greg DOH! Ok, I'll check that out. That was probably one of the places I didn't think to check. And to think I've been working with Ed on trouble-shooting V9T9 relatively recently, you woulda thought that might be a good place to check. Thanks for the info! -Dano Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 26, 2014 Share Posted March 26, 2014 (edited) The SUBDIR is used to go into subdirectories like DSK1.MYART. or HDS1.ASM.SOURCE. which can be created with the HFDC or with GeneveOS, so you only need it if you have subdirectories on your image. Also, you can list both sector dumps ("v9t9") and track dumps ("pc99") and all supported hard disk image formats. The "ls" command allows you to collect the files and directories in a list for further processing. I'll check the issue with the speed (didn't notice). It only makes limited sense to accept a collection of image files in the command line with e.g. "*.dsk", because if you actually have a large number of disks the shell buffer may not be large enough to hold all expanded path names. Edited March 26, 2014 by mizapf Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 26, 2014 Share Posted March 26, 2014 And to think I've been working with Ed on trouble-shooting V9T9 relatively recently, you woulda thought that might be a good place to check. Is a new version of v9t9 in the works? Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 26, 2014 Share Posted March 26, 2014 (edited) Dano, try this instead: java -classpath tiimagetool.jar ti.image.CommandShell dir <Image file> This is running substantially faster for me. Edited March 26, 2014 by mizapf Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted March 26, 2014 Author Share Posted March 26, 2014 Is a new version of v9t9 in the works? Depends on what you mean by new. Within the last year or so, yes. He's re-written it in Java. Which made it interesting for me because I much prefer apps that I can run natively on my Mac and NOT have to VM into Windows. I've had a little trouble with my Mac here and there so I'm trying to work with him to figure that out. I fired it up last night and it worked but browsing directories was incredibly slow. Prior version didn't have that problem. Give it a lookie-loo here: V9T9 Emulator Since his re-write, he's included support for CorComp FDC, and PCODE as well. And Ed (author) is pretty responsive and helped whenever I've asked help of him. Cheers! -Dano Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted March 26, 2014 Author Share Posted March 26, 2014 Dano, try this instead: java -classpath tiimagetool.jar ti.image.CommandShell dir <Image file> This is running substantially faster for me. OH YEAH, much quicker! And thanks for the explanation of the SUBDIR argument. Duh, I shoulda probably picked that up since your tool also deals with HDD images. Do floppys actually support sub-directories? Seemed like I read somewhere that wasn't officially supported but seemed like I could do it. I don't remember the circumstances though. I'm going to go with the assumption that 99.9% of the DSK images won't have sub-directories. Which brings me to another question regarding the SUBDIR argument. Is that argument just an option to view files of ONLY a sub-directory? And is it recursive? Thanks again, much appreciate your feedback! -Dano Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 26, 2014 Share Posted March 26, 2014 (edited) From time to time I still learn new things in Java ... The first invocation (with -jar) made the class loader fetch the ti.image.TIImageTool class (declared as the main class within the jar manifest), which references some Swing classes (graphic toolkit). Although no window is brought up, this seems to imply a lot of additional (but useless) class loading, maybe also initialisations in static parts. The second variant loads ti.image.CommandShell which does not reference TIImageTool itself but only the support classes for interpreting images. Accordingly, no Swing elements are loaded, and things become much faster. The HFDC has support for floppy directories, but (as with GeneveOS) only for three subdirectories in the root directory and no deeper nesting. The SUBDIR argument is comparable to the argument of directory list commands in DOS or Unix shells. That is, if you have a directory ABC on your floppy disk or hard disk, you get a directory listing of ABC if you add it as the final argument (CommandShell dir imagefile.dsk ABC). On my hard disk, I can use "CommandShell dir myharddisk.hd ASM.DIV.PROG" to get a list of all files (and subdirectories) of the directory HDS1.ASM.DIV.PROG. If you have some skills in shell programming, you may be interested in the "lsf" command. It decorates directories with a ".d" suffix. That way you can implement a recursive search in a script file by getting the names, looking for strings with the ".d" suffix, and using them for a new invokation (clipping off that suffix, of course). The lsf command also decorates file names of type DIS/VAR 80 with a ".t" suffix. Again, you may make use of that, for instance, to implement a search tool in a shell script. (BTW, I uploaded yet another version, now including a "type" command for text file output.) Did I already say that I love script programming? Edited March 26, 2014 by mizapf Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted March 26, 2014 Author Share Posted March 26, 2014 From time to time I still learn new things in Java ... The first invocation (with -jar) made the class loader fetch the ti.image.TIImageTool class (declared as the main class within the jar manifest), which references some Swing classes (graphic toolkit). Although no window is brought up, this seems to imply a lot of additional (but useless) class loading, maybe also initialisations in static parts. The second variant loads ti.image.CommandShell which does not reference TIImageTool itself but only the support classes for interpreting images. Accordingly, no Swing elements are loaded, and things become much faster. The HFDC has support for floppy directories, but (as with GeneveOS) only for three subdirectories in the root directory and no deeper nesting. The SUBDIR argument is comparable to the argument of directory list commands in DOS or Unix shells. That is, if you have a directory ABC on your floppy disk or hard disk, you get a directory listing of ABC if you add it as the final argument (CommandShell dir imagefile.dsk ABC). On my hard disk, I can use "CommandShell dir myharddisk.hd ASM.DIV.PROG" to get a list of all files (and subdirectories) of the directory HDS1.ASM.DIV.PROG. If you have some skills in shell programming, you may be interested in the "lsf" command. It decorates directories with a ".d" suffix. That way you can implement a recursive search in a script file by getting the names, looking for strings with the ".d" suffix, and using them for a new invokation (clipping off that suffix, of course). The lsf command also decorates file names of type DIS/VAR 80 with a ".t" suffix. Again, you may make use of that, for instance, to implement a search tool in a shell script. (BTW, I uploaded yet another version, now including a "type" command for text file output.) Did I already say that I love script programming? Since I haven't figured out how to break up a quote I'll have to reply to your the whole thing. Thanks for the explaination of the sub-directories. That's bringing back some memory. I think I was using emulation and accidentally created a sub-directory and didn't realize I could do that. I tried the 'lsf' command and thought it was a bug with the extensions. Now it makes more sense. I still like the output of the dir, as my goal is to create one huge text file with all the supplemental file data in clear text. I could see the 'lsf' command being useful for database creation and logic steering though. Speaking of 'dir' command. Out of curiosity; why 'dir' and not 'ls -l' or 'ls -al'? As always, thank you for making ANY of this happen!!! Cheers! -Dano Quote Link to comment Share on other sites More sharing options...
+mizapf Posted March 26, 2014 Share Posted March 26, 2014 Why "dir"? - Quite simple: "ls -al" are two words, and they appear as two separate arguments. Also, I used "type" and not "cat" for a text file output. I don't want to imply that you get something like a shell with all of its functions. You may have noticed that "lsf" is an analogy to "ls -F". And actually, $ alias dir alias dir='ls -l' Quote Link to comment Share on other sites More sharing options...
CantStopClicking Posted March 27, 2014 Author Share Posted March 27, 2014 Why "dir"? - Quite simple: "ls -al" are two words, and they appear as two separate arguments. Also, I used "type" and not "cat" for a text file output. I don't want to imply that you get something like a shell with all of its functions. You may have noticed that "lsf" is an analogy to "ls -F". And actually, $ alias dir alias dir='ls -l' I figured that's what the 'lsf' was representing. I just thought it was funny you had dir in there instead of 'lsal'. All good. Don't make a lick of difference to me as long as it does what it's intended and it definitely does that! :-) Cheers! -Dano Quote Link to comment Share on other sites More sharing options...
RXB Posted March 27, 2014 Share Posted March 27, 2014 From time to time I still learn new things in Java ... The first invocation (with -jar) made the class loader fetch the ti.image.TIImageTool class (declared as the main class within the jar manifest), which references some Swing classes (graphic toolkit). Although no window is brought up, this seems to imply a lot of additional (but useless) class loading, maybe also initialisations in static parts. The second variant loads ti.image.CommandShell which does not reference TIImageTool itself but only the support cl Quote Link to comment Share on other sites More sharing options...
+Lee Stewart Posted March 28, 2014 Share Posted March 28, 2014 From time to time I still learn new things in Java ... The first invocation (with -jar) made the class loader fetch the ti.image.TIImageTool class (declared as the main class within the jar manifest), which references some Swing classes (graphic toolkit). Although no window is brought up, this seems to imply a lot of additional (but useless) class loading, maybe also initialisations in static parts. The second variant loads ti.image.CommandShell which does not reference TIImageTool itself but only the support cl Are you saying you also learn new things in Java, Rich? ...lee Quote Link to comment Share on other sites More sharing options...
RXB Posted March 29, 2014 Share Posted March 29, 2014 Are you saying you also learn new things in Java, Rich? ...lee Naw I just do not like Command-shell. Quote Link to comment Share on other sites More sharing options...
TheMole Posted June 18, 2014 Share Posted June 18, 2014 Michael, does tiimagetool also support adding importing files into a disk image from the command line? I'm looking for an OSX compatible tool that does this that I can integrate in a Makefile. Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 18, 2014 Share Posted June 18, 2014 It once was able to, then the GUI became more powerful, now I'm gradually bringing the command line features back. Import from the command line does not work right now, but you can import a whole directory full of TIFILES into a disk image, if that is somewhat helpful for you. Right now I'm preparing the next evolution of TIImageTool, featuring Drag and Drop. For that reason I cannot add the requested feature right now, being right in the middle. Quote Link to comment Share on other sites More sharing options...
TheMole Posted June 18, 2014 Share Posted June 18, 2014 It once was able to, then the GUI became more powerful, now I'm gradually bringing the command line features back. Import from the command line does not work right now, but you can import a whole directory full of TIFILES into a disk image, if that is somewhat helpful for you. Right now I'm preparing the next evolution of TIImageTool, featuring Drag and Drop. For that reason I cannot add the requested feature right now, being right in the middle. Okay, good to know, thanks. In the mean time I found a solution to my specific problem: the "disk" program, part of the ti99sim emulator suite, does the job perfectly for what I need. I no longer have to start a GUI program to add files to a disk image, it's all just a simple "make install" away . So no rush, drag&drop support sounds like a nice thing to have, and should be a good step forward for those who prefer to use a GUI program for this. Quote Link to comment Share on other sites More sharing options...
RXB Posted June 18, 2014 Share Posted June 18, 2014 I can not wait for SCSI support on MESS as HFDC is crap compared to SCSI. Really only directories 3 deep is a junk design. On real hardware using a SCSI I had Directories 7 deep and that made organizing stuff much more easy to remember where it was. Example: RUN "SCS2.XB.XBTOOLS.XBVIDEO.XBLINKS.XBPLOT.LOAD" The RXB LOAD program took care of the paths for loading from this path for even the XB ASSEMBLY SUPPORT by using CALL BLOAD instead of using CALL LOAD OMG I miss my SCSI card! Quote Link to comment Share on other sites More sharing options...
+mizapf Posted June 18, 2014 Share Posted June 18, 2014 Really? I don't know of any depth limitation with HFDC. Or is it because I'm using GeneveOS to write to the hard disk? I just had a look at the HFDC manual. Page 12, last section: You can set up as many levels of subdirectories within subdirectories as you wish, subject only to some practical limits as to how many characters it takes to address them. [...] The total name can be up to 40 characters long. Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted June 18, 2014 Share Posted June 18, 2014 I also seem to remember that the SCSI card used the same directory logic to keep things compatible. . . Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.