From: Stuart Morrow <morrow.stuart@gmail.com>
To: 9front@9front.org
Subject: Re: [9front] g
Date: Wed, 11 Aug 2021 20:15:14 +0000 [thread overview]
Message-ID: <CABB-WO8CZcT5SVTj0E_BkNsh+uHYEt4MA3WZBi6RbQkZQX8jeQ@mail.gmail.com> (raw)
In-Reply-To: <D1B674903EA670EF9DE147AC46D90A9A@eigenstate.org>
Yeah, I suppose it would also look in ?.awk, ?.cpp, ?.mk, and ?.rc.
I was about to solve this on my system with
nfile -m $files | awk -F\t '$2 ~ /^text|application.x-sh/ { print $1 }'
where nfile is a file(1) that actually uses a frog to separate,
but then that reads every file two times (once by nfile, once
by grep), so I suppose the right thing all along was to have a
grep that can identify binary files by itself (as on other OSes).
Anyway, while we're on the subject, is there anything that
actually relies on Plan 9's (and Research Unix's) wrong grep -c
behaviour? (If I want just the number of lines, I can do grep|wc…)
Anyway here's nfile:
diff file.c nfile.c
176c176
< void type(char*, int);
---
> void type(char*);
223,226d222
< int i, j, maxlen;
< char *cp;
< Rune r;
<
236,244d231
< maxlen = 0;
< if(mime == 0 || argc > 1){
< for(i = 0; i < argc; i++) {
< for (j = 0, cp = argv[i]; *cp; j++, cp += chartorune(&r, cp))
< ;
< if(j > maxlen)
< maxlen = j;
< }
< }
247c234
< print ("stdin: ");
---
> print("stdin\t");
251,252c238,239
< for(i = 0; i < argc; i++)
< type(argv[i], maxlen);
---
> for(int i = 0; i < argc; i++)
> type(argv[i]);
258c245
< type(char *file, int nlen)
---
> type(char *file)
260,272c247
< Rune r;
< int i;
< char *p;
<
< if(nlen > 0){
< slash = 0;
< for (i = 0, p = file; *p; i++) {
< if (*p == '/') /* find rightmost slash */
< slash = p;
< p += chartorune(&r, p); /* count runes */
< }
< print("%s:%*s",file, nlen-i+1, "");
< }
---
> print("%s\t", file);
--- //.git/fs/object/a9bccf9e9b1bd408629edaac277f6b3a3a4ab6fb/tree/sys/man/1/file
+++ sys/man/1/file
@@ -106,7 +106,19 @@
.I file
decides its input is
binary.
+.PP
+.I Nfile
+is the same but
+filename and classification are tab-separated.
.SH SOURCE
.B /sys/src/cmd/file.c
+.br
+.B /sys/src/cmd/nfile.c
.SH BUGS
It can make mistakes.
+.br
+.I File
+should be implemented as an
+.I nfile
+wrapper.
+
--- //.git/fs/object/a9bccf9e9b1bd408629edaac277f6b3a3a4ab6fb/tree/sys/man/1/resample
+++ sys/man/1/resample
@@ -82,4 +82,5 @@
.B /sys/src/cmd/resize.c
.SH "SEE ALSO
.IR crop (1),
-.IR image (6)
+.IR image (6),
+.IR file (1)
(The relevance of file to resample is it's the easiest way to find out
an image's size and this isn't documented anywhere.)
next prev parent reply other threads:[~2021-08-11 20:30 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-10 18:03 Stuart Morrow
2021-08-11 1:13 ` ori
2021-08-11 20:15 ` Stuart Morrow [this message]
2021-08-11 20:32 ` Stuart Morrow
2021-08-12 5:38 ` Alex Musolino
2021-08-13 2:43 ` Alex Musolino
2021-08-14 21:38 ` Stuart Morrow
2021-08-14 21:45 ` Stuart Morrow
2021-08-15 2:42 ` Alex Musolino
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=CABB-WO8CZcT5SVTj0E_BkNsh+uHYEt4MA3WZBi6RbQkZQX8jeQ@mail.gmail.com \
--to=morrow.stuart@gmail.com \
--cc=9front@9front.org \
/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).