[Coco] Are the files in the /dd/SYS directory always ASCII ?

Jeff Teunissen deek at d2dc.net
Fri Sep 25 04:20:05 EDT 2020


Hmm, I don't see why file magic wouldn't work on OS9. You wouldn't be able
to use it interactively very well, but it works really well for figuring
out whether a file is text or not.

On Thu, Sep 24, 2020, 6:53 PM Rick Ulland <rickulland1 at gmail.com> wrote:

> Back in the 90's I completely abandoned trying to understand the OS9
> root or sub directory contents. Since I did not know about
> /home/username back then, I created a separate /dd/USR/program branch
> for any program data files I could place at will. I did this because
> MultiVue is also based on file extension, and needs the same data you
> want to compile.
>
> When you enter a directory, MultiVue caches each icon (*.aif) file it
> sees along the way, that assigns the program to use for a particular
> extension. Navigate direct to /dd/usr/dynastar, an AIF might declare
> .doc to be a binary dynastar save. Go to /dd/help, an AIF declares .doc
> as plaintext(prolly with an ancient CI$ sig at the bottom:-) todump to a
> overlay window. Unfortunately, things fall apart as you move around, but
> they had a thought.
>
> I don't think anybody spends that much time organizing their OS9 any
> more, but without Unix magic file type bytes and outside of  a few dead
> ringers like .txt, you sort of have to start with absolute location plus
> full filename, then some kind of .aif file mapper in case Multivue is
> installed and modifies the default values in some locations, and
> finally, some guesses based on typical extension. It's quite a task.
>
> Anyway, I never added anything outside of /dd/USR, so this half
> recovered hard drive might not a have a huge example set, but it's a
> clean sample of placement overruling file extension...
>
> CMDS    - binarys, ICONS dir (multivue icon bitmaps)
> COM     - KBCOM dialer dir
> DATA    - BvdP ‘diskcat’ data files
> DEFS    - C compiler header files
> DOCS    - text .doc files from way back
> INPUTQ  - KBCOM input queue
> KA9Q    - all things KA9Q(qv)
> LIB     - C compiler library files
> LOG     - cron logs
> OUTPUTQ – KBCOM output queue
> SYS     - ad hoc per filename
>     CLIP    - from some gfx program
>     DIAL    - from some telecom program
>     ETHAWIN – etahwin txt cfg files (I blame Allen)
>     FONTS   - binary fonts dir
>
> And then anything the user might edit lies in /dd/USR/program, where each
> program can claim any file extension via .aif and so Good Luck With That.
>
> I should compare this to Nitros9, I'm sure they have more to add but
> that is a whole project for next big snowfall.
>
> -rick
>
>
>
> On 9/24/20 3:18 PM, Jeff Teunissen wrote:
> > Text directory list? I don't know to what this refers, but it smells of
> > "not the best approach".
> >
> > On Thu, Sep 24, 2020, 11:00 AM <coco at jechar.ca> wrote:
> >
> >> Ok so I will not put /dd/sys on the text directory list.
> >>
> >> On 2020-09-23 21:39, L. Curtis Boyle wrote:
> >>> Fonts aren’t really, or the stdptrs, etc.
> >>>
> >>> Sent from my iPhone
> >>>
> >>>> On Sep 23, 2020, at 6:16 PM, coco at jechar.ca wrote:
> >>>>
> >>>> 
> >>>> I have not encountered any exceptions myself.
> >>>>
> >>>> Charlie
> >>>>
> >>>> --
> >>>> Coco mailing list
> >>>> Coco at maltedmedia.com
> >>>> https://pairlist5.pair.net/mailman/listinfo/coco
> >>>>
> >> --
> >> Coco mailing list
> >> Coco at maltedmedia.com
> >> https://pairlist5.pair.net/mailman/listinfo/coco
> >>
>
>
> --
> Coco mailing list
> Coco at maltedmedia.com
> https://pairlist5.pair.net/mailman/listinfo/coco
>


More information about the Coco mailing list