9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Jeff Sickel <jas@corpus-callosum.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] a question of file and the history of magic
Date: Sun,  6 Jul 2008 16:00:22 -0500	[thread overview]
Message-ID: <F9CABF82-1682-4B68-8EDC-CFC7438EABF8@corpus-callosum.com> (raw)
In-Reply-To: <88a8e092b7ba03b80e5bdef0cc0f96f2@quanstro.net>


On Jul 6, 2008, at 2:30 PM, erik quanstrom wrote:

>> This addition helped my scripts become a little more streamlined, but
>> of course puts in an additional entry into the source file I need to
>> track.  As file name extensions don't always work across all sorts of
>> systems, many still hamstrung by 8.3, what is the preferred or
>> recommend mechanism for checking file types the Plan 9 way since we
>> no
>> longer have the System V magic?
>
> i'm pretty confused by what you're saying here.  why doesn't file(1)
> work?
> are you saying there's something wrong with editing the source as
> opposed
> to to editing a configuration file?


File does work; until I need to check for something not in its
compiled-in magic tables.  So I patch the code and it works better
than many other options I've tried while still letting me use rc to
script out things I need to get done without the restart time of
trying to remember what the script does when I need to add to it later
(unlike the brick wall I continually hit all the time when using Perl).

In a sense, the question is more about the historical change and/or
adoption of a new file command for Plan 9 that doesn't use a magic
file for references.  Why opt out of a magic file other than the
obvious performance hit of scanning it each run?  Is it worth
repeating the old forms that used magic, or has anyone in the Plan 9
community already improved upon the idea and introduced a new, more
adaptable tool?

> either way your system is equally non-standard.  in either event,
> submitting a patch and having it accepted is the only way around this.

The beauty of standards is there are so many to choose from -- oft
quoted and most likely misappropriated from somewhere else.

> 	dd -if $infile -bs $nbytes -count 1 | xd

dang, I almost always forget about dd for some reason.  Though in that
case I'd need to pull in Plan 9's version of dd into p9p since the
arguments to dd are different on almost every system I use: Plan 9,
various Linux distros, Solaris, OS X, ...

-jas




  reply	other threads:[~2008-07-06 21:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-06 19:30 erik quanstrom
2008-07-06 21:00 ` Jeff Sickel [this message]
  -- strict thread matches above, loose matches on Subject: below --
2008-07-07  8:58 Harri Haataja
2008-07-11 16:21 ` Dan Cross
2008-07-06 23:45 geoff
2008-07-06 21:20 erik quanstrom
2008-07-06 21:59 ` Brantley Coile
2008-07-06 22:31 ` Bakul Shah
2008-07-06 22:44   ` Charles Forsyth
2008-07-06 18:16 Jeff Sickel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F9CABF82-1682-4B68-8EDC-CFC7438EABF8@corpus-callosum.com \
    --to=jas@corpus-callosum.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).