[9fans] split(1): -e vs. -n, -f
hi list, both behavior and code indicate that split(1)'s `-e' (split by regular expression) doesn't play along with either `-n' (line count) or `-f' (output file prefix). the former is somewhat understandable, but the later is strange in lieu of `-s' (output file suffix) working just fine. that by accident or is there some rationale? -- dexen deVries [[[↓][→]]]
Re: [9fans] split(1): -e vs. -n, -f [patch]
On Monday 30 of December 2013 11:10:45 you wrote:
> both behavior and code indicate that split(1)'s `-e' (split by regular
> expression) doesn't play along with either `-n' (line count) or `-f' (output
> file prefix). the former is somewhat understandable, but the later is
> strange in lieu of `-s' (output file suffix) working just fine.
>
> that by accident or is there some rationale?
--
dexen deVries
[[[↓][→]]]
>From 01ae77413e4249776124727e797b0172e7874987 Mon Sep 17 00:00:00 2001
From: dexen deVries
Date: Mon, 30 Dec 2013 15:47:24 +0100
Subject: [PATCH] make stat(1)'s `-e' play along with `-f' (output file
prefix)
also make the file pathname buffer a bit larger.
---
src/cmd/split.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/src/cmd/split.c b/src/cmd/split.c
index e758786..4820930 100644
--- a/src/cmd/split.c
+++ b/src/cmd/split.c
@@ -8,7 +8,7 @@ char digit[] = "0123456789";
char *suffix = "";
char *stem = "x";
char suff[] = "aa";
-char name[200];
+char name[2048];
Biobuf bout;
Biobuf *output = &bout;
@@ -130,9 +130,11 @@ int
matchfile(Resub *match)
{
if(match[1].s.sp) {
- int len = match[1].e.ep - match[1].s.sp;
- strncpy(name, match[1].s.sp, len);
- strcpy(name+len, suffix);
+ int len_match = match[1].e.ep - match[1].s.sp;
+ int len_stem = strlen(stem);
+ strcpy(name, stem);
+ strncpy(name+len_stem, match[1].s.sp, len_match);
+ strcpy(name+len_stem+len_match, suffix);
openf();
return 1;
}
--
1.7.12.1
Re: [9fans] split(1): -e vs. -n, -f
On Mon Dec 30 05:12:16 EST 2013, dexen.devr...@gmail.com wrote:
> hi list,
>
>
> both behavior and code indicate that split(1)'s `-e' (split by regular
> expression) doesn't play along with either `-n' (line count) or `-f' (output
> file prefix). the former is somewhat understandable, but the later is strange
> in lieu of `-s' (output file suffix) working just fine.
>
> that by accident or is there some rationale?
i think the answer is a little bit of both. it's easy to make split support
mixing any number of regular expressions with one line count. (i believe
using -f with -e works already, unless you want a prefix for even re-matched
files.
proposed version attached
- erik
---
; whatis x xx
x=(1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20)
fn xx {for(i in $x)echo $i}
; xx | $home/v.split -e '^7$' -n 10
; for(i in *)echo $i && mc $i
xaa
1 2 3 4 5 6
xab
7 8 9 10
xac
11 12 13 14 15 16 17 18 19 20
; xx|$home^/v.split -f X -e '^7$' -n 10
; lc
Xaa Xab Xac
; xx|$home^/v.split -e '^(1)$' -e '^(7)$' -n 10
; for(i in *)echo $i && mc $i
1
1 2 3 4 5 6
7
7 8 9 10
xaa
11 12 13 14 15 16 17 18 19 20#include
#include
#include
#include
chardigit[] = "0123456789";
char*suffix = "";
char*stem = "x";
charsuff[] = "aa";
charname[200];
Biobuf bout;
Biobuf *output;
int iflag;
int xflag;
void openf(void);
int nextf(void);
int matchfile(Resub*);
int matching(Reprog**, int, char*);
char* xlower(char*);
void usage(void);
void
main(int argc, char *argv[])
{
char *pat[25], *line, buf[256];
int i, n, npat, lineno;
Biobuf bin, *b;
Reprog *re[25];
n = 0;
b = &bin;
npat = 0;
ARGBEGIN {
case 'l':
case 'n':
n=atoi(EARGF(usage()));
break;
case 'e':
if(npat == nelem(pat))
sysfatal("split: too many pats");
pat[npat++] = EARGF(usage());
break;
case 'f':
stem = EARGF(usage());
break;
case 's':
suffix = EARGF(usage());
break;
case 'x':
xflag++;
break;
case 'i':
iflag++;
break;
default:
usage();
break;
} ARGEND;
if(argc > 1)
usage();
else if(argc == 0)
Binit(b, 0, OREAD);
else{
b = Bopen(argv[0], OREAD);
if(b == nil)
sysfatal("split: Bopen %s: %r", argv[0]);
}
/* default */
if(n == 0 && npat == 0)
n = 1000;
/* prepare regular reressions */
for(i = 0; i < npat; i++){
re[i] = regcomp(xlower(pat[i]));
if(re[i] == nil)
sysfatal("split: bad regular reression: %s", pat[i]);
}
lineno = 0;
while((line = Brdline(b,'\n')) != nil) {
line[Blinelen(b)-1] = 0;
lineno++;
if(matching(re, npat, line)){
if(xflag)
continue;
}else if(n > 0 && lineno > n){
nextf();
lineno = 1;
}else if(output == nil)
nextf();
Bwrite(output, line, Blinelen(b)-1);
Bputc(output, '\n');
}
while((n = Bread(b, buf, sizeof(buf))) > 0)
Bwrite(output, buf, n);
Bterm(b);
exits("");
}
enum {
Base= 26,
Last= Base*(Base-1) + (Base-1),
};
int
nextf(void)
{
static int once, seq;
if(seq > Last){
if(!once)
fprint(2, "split: file %szz not split\n", stem);
once = 1;
return 0;
}
snprint(name, sizeof name, "%s%c%c", stem, 'a'+seq/26, 'a'+seq%26);
seq++;
openf();
return 1;
}
void
openf(void)
{
static int fd = -1;
if(fd >= 0){
Bterm(output);
close(fd);
}
fd = create(name, OWRITE,0666);
if(fd < 0)
sysfatal("split: can't create %s: %r", name);
output = &bout;
Binit(output, fd, OWRITE);
}
int
matching(Reprog **re, int nre, char *line)
{
char *p;
int i, len;
Resub m[2];
p = xlower(line);
for(i = 0; i < nre; i++){
memset(m, 0, sizeof m);
if(regexec(re[i], p, m, nelem(m))){
if(m[1].sp == nil)
return nextf();
len = m[1].ep - m[1].sp;
[9fans] 9front sleep interrupted in kproc?
not sure where to send this comment. i think this patch misunderstands the situation. the patch claims that some code is wrong because sleep in a kproc might get interrupted. http://code.google.com/p/plan9front/source/detail?r=3864ff1fe83f254622e6f10925f53df62255336d this diff highlights the issue http://code.google.com/p/plan9front/source/diff?spec=svn3864ff1fe83f254622e6f10925f53df62255336d&r=3864ff1fe83f254622e6f10925f53df62255336d&format=side&path=/sys/src/9/port/alarm.c the crux of the matter is when sleep might be interrupted. sleep is interrupted iff process received a note. since kprocs don't get notes (it's an error to write to the note file), sleep in a kproc can't get interrupted. this code will never fire. - erik
[9fans] long mode -> 32-bit mode
has anyone got code for amd64 to go from long mode to 32 bit mode? in theory it's just a retfq, but evidently it's not quite that simple. ;-) - erik
Re: [9fans] "gpio device" for Plan 9
This is pretty cool! Good work! I have a question - what would the maximum ISR rate be for a rising edge of a square wave sampled on one of the GPIO pins? At the link: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=72&t=33113 Its quoted to be 10,000 events per second using a standard ISR. Of course, thats under Linux. It also says it can be 100,000 events per second using a modified ISR, but I only need to sample the rising edge of a 10kHz square wave. Lastly, I hope this email is seen by the list - "When it is all mouth, and no ears, its known as an 'alligator'..." On Mon, Dec 30, 2013 at 6:32 PM, Skip Tavakkolian < skip.tavakkol...@gmail.com> wrote: > nice. i guess i'll need to get a Pi T-Cobbler and try it. > > > > On Sun, Dec 29, 2013 at 2:04 PM, Krystian Lewandowski < > krystian@gmail.com> wrote: > >> Good evening, >> i’d like to share with you some Raspberry Pi related work done for Plan 9 >> BCM port. >> >> Using slightly modified (unmodified in most cases) uartmini.c GPIO >> functions i implemented #G/gpio device: >> Structure is as follows: >> #G/gpio/ >> /bcm/ ... >> /board/ ... >> /wpi/ ... >> /OK >> >> - bcm uses board revision specific pin numbering >> - board uses human readable pin addressing (board revision agnostic) >> - wpi uses wiringPi pin assignment (board revision agnostic) >> - OK pin can be used to switch on/off OK LED on the board >> >> Each directory above contains files that are mapped to pins. >> Maybe it is an overkill, i don’t know. >> >> I used this page as reference for pin assignments: >> https://projects.drogon.net/raspberry-pi/wiringpi/pins/ >> >> % du -a >> 0 ./bcm/0 >> 0 ./bcm/1 >> 0 ./bcm/4 >> 0 ./bcm/7 >> 0 ./bcm/8 >> 0 ./bcm/9 >> 0 ./bcm/10 >> 0 ./bcm/11 >> 0 ./bcm/14 >> 0 ./bcm/15 >> 0 ./bcm/16 >> 0 ./bcm/17 >> 0 ./bcm/18 >> 0 ./bcm/21 >> 0 ./bcm/22 >> 0 ./bcm/23 >> 0 ./bcm/24 >> 0 ./bcm/25 >> 0 ./bcm >> 0 ./board/SDA >> 0 ./board/SCL >> 0 ./board/GPIO7 >> 0 ./board/CE1 >> 0 ./board/CE0 >> 0 ./board/MISO >> 0 ./board/MOSI >> 0 ./board/SCLK >> 0 ./board/TxD >> 0 ./board/RxD >> 0 ./board/GPIO0 >> 0 ./board/GPIO1 >> 0 ./board/GPIO2 >> 0 ./board/GPIO3 >> 0 ./board/GPIO4 >> 0 ./board/GPIO5 >> 0 ./board/GPIO6 >> 0 ./board >> 0 ./wpi/8 >> 0 ./wpi/9 >> 0 ./wpi/7 >> 0 ./wpi/11 >> 0 ./wpi/10 >> 0 ./wpi/13 >> 0 ./wpi/12 >> 0 ./wpi/14 >> 0 ./wpi/15 >> 0 ./wpi/16 >> 0 ./wpi/0 >> 0 ./wpi/1 >> 0 ./wpi/2 >> 0 ./wpi/3 >> 0 ./wpi/4 >> 0 ./wpi/5 >> 0 ./wpi/6 >> 0 ./wpi >> 0 ./OK >> 0 . >> >> Reference: >> - mount gpio: >> % bind -a '#G’ /dev >> - read pin state: >> % cat /dev/gpio/board/GPIO0 >> - write pin state: >> % echo 1 > /dev/gpio/board/GPIO0 >> % echo 0 > /dev/gpio/board/GPIO0 >> - select pin function: >> % echo func out > /dev/gpio/board/GPIO0 >> (possible functions are: "in", "out", "f5", "f4", "f0", "f1", "f2", "f3”) >> - select pin pull state: >> % echo pull up > /dev/gpio/board/GPIO0 >> (possible pull states are: "off", "down", "up”) >> >> This is completely untested. I’m still waiting for cables and breadboard, >> i don’t want to play with pins until i’ll have it. Though OK pin (LED) >> seems to behave. >> Maybe something in this implementation is wrong or has no sense at all? >> If anyone would like to try to play with it, here is the commit (also >> includes /dev/cputemp i sent to this list some time ago). I don’t want to >> send the patch yet. >> >> https://github.com/elewarr/plan9-bcm/commit/18f1c470d1e16a63a55761094f723c2bd91b576d >> Please remember it is not tested - use it at your own risk. >> >> Other things: >> 1. OK LED is also used by emmc.c (search for okay(int)) >> 2. devgpio.c keeps its own version of some GPIO related functions(gpio >> in/out, function selection, pull up/down state) defined in uartmini.c - it >> should probably be removed from uartmini.c but because i can’t test serial >> console connection i didn’t touch it >> 3. Is #G/gpio scheme OK (unreserved, correct)? >> 4. Events are not supported >> >> Greetings, >> Krystian >> > >
Re: [9fans] 9front sleep interrupted in kproc?
erik quanstrom once said: > since kprocs don't get notes (it's an error to write to the note file), > sleep in a kproc can't get interrupted. this code will never fire. It looks like they can on 9front. The following is from pc/vgavesa.c:/^vesaproc /* * dont wait forever here. some BIOS get stuck * in i/o poll loop after blank/unblank for some * reason. (Thinkpad A22p) */ procalarm(1); Cheers, Anthony
Re: [9fans] 9front sleep interrupted in kproc?
Anthony Martin once said: > erik quanstrom once said: > > since kprocs don't get notes (it's an error to write to the note file), > > sleep in a kproc can't get interrupted. this code will never fire. > > It looks like they can on 9front. Actually, this isn't just 9front. All of the network medium receive kprocs (e.g., etherread4) can be sent notes (only by the kernel, of course). Anthony
[9fans] Vanilla Plan 9 or one of the flavors?
Hi, After a number of months of lurking on this list, I've finally gotten a computer set up to be a dedicated Plan 9 installation (as part of a grid, of course). At this point, I need to choose between vanilla Plan 9 or one of the flavors (9front or 9atom). I have read the "9front vs. 9atom" thread; prevailing wisdom seems to say to go with 9atom unless you need the hardware support of 9front - please correct me if this is wrong. That being said, the thread didn't talk about the vanilla Plan 9 distribution from Bell Labs. The computer I'm installing it on is ~15 years old, so I doubt it will have all that many hardware support issues. Basically, would you guys recommend I try the Bell Labs distribution of Plan 9, 9front, or 9atom as my first installation? I've also done a cursory search of the list archives without finding anything; if this has been covered before, please accept my apologies. Thanks for your time, Alex Jordan
Re: [9fans] Vanilla Plan 9 or one of the flavors?
On Mon, Dec 30, 2013 at 6:02 PM, Alex Jordan wrote: > At this point, I need to choose between vanilla Plan 9 or one of the > flavors (9front or 9atom). There is also 9legacy, which I forgot about.
Re: [9fans] Vanilla Plan 9 or one of the flavors?
On Mon Dec 30 21:03:24 EST 2013, alexander3223...@gmail.com wrote: > Hi, > After a number of months of lurking on this list, I've finally gotten > a computer set up to be a dedicated Plan 9 installation (as part of a > grid, of course). > At this point, I need to choose between vanilla Plan 9 or one of the > flavors (9front or 9atom). I have read the "9front vs. 9atom" thread; > prevailing wisdom seems to say to go with 9atom unless you need the > hardware support of 9front - please correct me if this is wrong. > That being said, the thread didn't talk about the vanilla Plan 9 > distribution from Bell Labs. The computer I'm installing it on is ~15 > years old, so I doubt it will have all that many hardware support > issues. Basically, would you guys recommend I try the Bell Labs > distribution of Plan 9, 9front, or 9atom as my first installation? > I've also done a cursory search of the list archives without finding > anything; if this has been covered before, please accept my apologies. well let me know if i can answer any questions or fix anything. funny how we all get pigeon holed. i thought i did 9atom to support more hardware. :-) - erik
Re: [9fans] 9front sleep interrupted in kproc?
On Mon Dec 30 20:26:47 EST 2013, al...@pbrane.org wrote: > Anthony Martin once said: > > erik quanstrom once said: > > > since kprocs don't get notes (it's an error to write to the note file), > > > sleep in a kproc can't get interrupted. this code will never fire. > > > > It looks like they can on 9front. > > Actually, this isn't just 9front. All of the network > medium receive kprocs (e.g., etherread4) can be sent > notes (only by the kernel, of course). there are no calls to procalarm() outside of sysalarm (the alarm system call) in either the official sources or 9atom (either the 64bit or regular kernels). if i've pulled correctly, 9front has one procalarm, and it's in the vesa code with a waserror at the ready. this patch addresses a problem that doesn't exist. it seems to imply that notes can come to kprocs out of the blue. and i believe this is not correct. - erik
