From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <88a8e092b7ba03b80e5bdef0cc0f96f2@quanstro.net> From: erik quanstrom Date: Sun, 6 Jul 2008 15:30:45 -0400 To: jas@corpus-callosum.com, 9fans@9fans.net MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] a question of file and the history of magic Topicbox-Message-UUID: dc46e4f8-ead3-11e9-9d60-3106f5b1d025 > 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? either way your system is equally non-standard. in either event, submitting a patch and having it accepted is the only way around this. > In a sense, a modified xd(1) that has an option for a restricted range > of byte sequences would work. That would at least provide a fast seek > into a file that can be pipelined into any other command sequence--no > need to dump the whole file when you just need to the first four > bytes, but then it just gets to the point of having a magic file. why would xd need modification? how about dd -if $infile -bs $nbytes -count 1 | xd there are no restrictions placed by dd on $nbytes. it could be 4 or 99132 or whatever. dd's -iseek option similarly can specify any offset. - erik