9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] sam question
@ 2008-07-17 22:56 Skip Tavakkolian
  2008-07-18  0:28 ` erik quanstrom
  0 siblings, 1 reply; 53+ messages in thread
From: Skip Tavakkolian @ 2008-07-17 22:56 UTC (permalink / raw)
  To: 9fans

related to the earlier discussion, for stripping the \r at the end of
lines in windows files, i use:

	,x/<CR>$/ c//

where <CR> is a cut&pasted return char (yes, i could use '.' instead,
but i'm paranoid.) x doesn't seem to recognize \r as a escape
sequence.  true?




^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [9fans] Sam question
@ 2001-08-20 12:06 bwc
  0 siblings, 0 replies; 53+ messages in thread
From: bwc @ 2001-08-20 12:06 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 146 bytes --]

Ooops.  Last time I respond in a hurry!

I meant to type Ken, Dennis and friends didi NOT suffer from `goto phobia.'

Oh well.

  Brantley

[-- Attachment #2: Type: message/rfc822, Size: 1408 bytes --]

From: bwc@borf.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Sam question
Date: Sun, 19 Aug 2001 11:05:27 -0400
Message-ID: <20010819150437.A9C4F199E8@mail.cse.psu.edu>

> I believe "goto" was retained in C for the benefit of code
> generators.

Then you never read any of Ken Thompson's code.  Goto is i C
because is was used!  I suspect Ken, Dennis and friends did
suffer from `goto phobia'.

Besides, every statement has an implied `goto' to the 
next statement :)

Does anyone have the Knuth reference on this subject?

  Brantley

^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [9fans] Sam question
@ 2001-08-19 18:06 rob pike
  0 siblings, 0 replies; 53+ messages in thread
From: rob pike @ 2001-08-19 18:06 UTC (permalink / raw)
  To: 9fans

I think the goto issue has been discussed enough, don't you?

-rob



^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [9fans] Sam question
@ 2001-08-19 15:05 bwc
  2001-08-19 15:59 ` Boyd Roberts
  0 siblings, 1 reply; 53+ messages in thread
From: bwc @ 2001-08-19 15:05 UTC (permalink / raw)
  To: 9fans

> I believe "goto" was retained in C for the benefit of code
> generators.

Then you never read any of Ken Thompson's code.  Goto is i C
because is was used!  I suspect Ken, Dennis and friends did
suffer from `goto phobia'.

Besides, every statement has an implied `goto' to the 
next statement :)

Does anyone have the Knuth reference on this subject?

  Brantley


^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [9fans] Sam question
@ 2001-08-19 12:44 rob pike
  0 siblings, 0 replies; 53+ messages in thread
From: rob pike @ 2001-08-19 12:44 UTC (permalink / raw)
  To: 9fans

> I believe "goto" was retained in C for the benefit of code
> generators.

False.

-rob



^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [9fans] Sam question
@ 2001-08-18  7:38 nigel
  2001-08-18  8:31 ` Steve Kilbane
                   ` (3 more replies)
  0 siblings, 4 replies; 53+ messages in thread
From: nigel @ 2001-08-18  7:38 UTC (permalink / raw)
  To: 9fans

OK, so 8 space tabs, ridiculously long variable names, unnecessary
nesting, hungarian notation, and insuffcient use of subfunctions
blows the 80 column limit too quickly.

So use more columns! When did you last use a VT100?

As for clarity, a consistent style is all that is required. Within bounds, it
doesn't matter so much what the style is. The assistance it gives in
reading other people's code is immense.

Programmers should be flexible enough to communicate in the local
dialect whether it be OTB, or something widly different.



^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [9fans] Sam question
@ 2001-08-17 22:35 David Gordon Hogan
  2001-08-18  4:47 ` Rick Hohensee
  2001-08-19  6:29 ` Lucio De Re
  0 siblings, 2 replies; 53+ messages in thread
From: David Gordon Hogan @ 2001-08-17 22:35 UTC (permalink / raw)
  To: 9fans

> I hear this argument from Gnuers and the like.  If it's a problem,
> your identifiers are too long or your functions are too long (thus
> your block nesting is too deep).  In the case of Gnu code, both are
> true.

Another common reason is that people don't know how to use continue.
Eg, instead of writing:

	for(p = example; p != nil; p = p->next) {
		q = p->fish;
		if(q->foo > 4 && q->bar < 3) {
			r = q->blarg;
			if(r->foo == 7) {
				dosomething(r);
				r->done++;
			}
		}
	}

it is stylistically preferable to write

	for(p = example; p != nil; p = p->next) {
		q = p->fish;
		if(q->foo <= 4 || q->bar >= 3)
			continue;
		r = q->blarg;
		if(r->foo != 7)
			continue;
		dosomething(r);
		r->done++;
	}

Notice the difference this makes in the indentation.
I think it's also slightly more readable, but YMMV.


^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [9fans] Sam question
@ 2001-08-17 22:22 geoff
  0 siblings, 0 replies; 53+ messages in thread
From: geoff @ 2001-08-17 22:22 UTC (permalink / raw)
  To: 9fans

> And indenting by eight zero-wide characters gets you wrapping around
> eighty zero-wide columns pretty quickly.

I hear this argument from Gnuers and the like.  If it's a problem,
your identifiers are too long or your functions are too long (thus
your block nesting is too deep).  In the case of Gnu code, both are
true.



^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [9fans] Sam question
@ 2001-08-17 17:00 rob pike
  0 siblings, 0 replies; 53+ messages in thread
From: rob pike @ 2001-08-17 17:00 UTC (permalink / raw)
  To: 9fans

Documented feature for old-thinkers, throwbacks, and whiners:
	tabstop=4 sam

-rob



^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [9fans] Sam question
@ 2001-08-17 16:32 David Gordon Hogan
  2001-08-17 16:55 ` Lucio De Re
                   ` (2 more replies)
  0 siblings, 3 replies; 53+ messages in thread
From: David Gordon Hogan @ 2001-08-17 16:32 UTC (permalink / raw)
  To: 9fans

> I carry around a utility I originally developed at Geotronics
> (early 1980s) called "retab" that transforms from one set of
> tabs stops to another in one pass; it can turn all tabs to an
> appropriate number of spaces by specifying -o +1.  The manual
> page could be improved, but here it is:

I am SO sick of C programs that are indented using spaces,
eg the GNU code which seems to have standardized on 2
space indent.  In the variable width font that I use, 2 spaces
is not a lot of indent, and the code is totally unreadable (as
opposed to being mostly unreadable, as it would be if it were
at least formatted correctly).

Real programmers indent with tabs.

Maybe the C preprocessor should reject any line that
starts with a space :-)



^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [9fans] Sam question
@ 2001-08-17 14:22 rob pike
  0 siblings, 0 replies; 53+ messages in thread
From: rob pike @ 2001-08-17 14:22 UTC (permalink / raw)
  To: 9fans

> ie. they move you from one field to the next.  a real bugger
>    when you _want_ to type a tab in a dialog box.

Again, old-think about tabs.

-rob



^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [9fans] Sam question
@ 2001-08-17 14:15 rob pike
  2001-08-17 16:58 ` Boyd Roberts
  2001-08-20  8:56 ` Douglas A. Gwyn
  0 siblings, 2 replies; 53+ messages in thread
From: rob pike @ 2001-08-17 14:15 UTC (permalink / raw)
  To: 9fans

People spend too much time fussing about how wide (read:
how many characters) a tab should be.  This "retab" program
is a perfect example of that old-think.

Tab stops, as computing uses them, become much less
meaningful in the world of variable-pitch fonts, the world
of today.  Someone needs to figure out how to make tab 
stops become true places on the screen, rather than just
an approximation simulated using the width of spaces
or numbers, without breaking the model of simple text
we've come to know and love.  It's a tough problem.

Meanwhile, the output from ls -l and ps is suffering, people.

-rob



^ permalink raw reply	[flat|nested] 53+ messages in thread
* Re: [9fans] Sam question
@ 2001-08-14 12:41 rob pike
  0 siblings, 0 replies; 53+ messages in thread
From: rob pike @ 2001-08-14 12:41 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 20 bytes --]

Try
	!unicode 8


[-- Attachment #2: Type: message/rfc822, Size: 1742 bytes --]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Sam question
Date: Tue, 14 Aug 2001 09:44:23 GMT
Message-ID: <3B73F61E.F60C9811@null.net>

gene garbutt wrote:
> I haven't figured out how to get the backspace character in sam command. I
> can snarf a backspace from the target file and do it that way, but I assume
> there must be a better way?

Not so far as I know.

^ permalink raw reply	[flat|nested] 53+ messages in thread
* [9fans] ls -R
@ 2001-08-08 10:45 rog
  2001-08-08 17:08 ` [9fans] Sam question gene garbutt
  0 siblings, 1 reply; 53+ messages in thread
From: rog @ 2001-08-08 10:45 UTC (permalink / raw)
  To: 9fans

[-- Attachment #1: Type: text/plain, Size: 874 bytes --]

sorry, boyd's response wasn't enormously helpful.

as far as i know the only plan 9 utility around that traverses the
file tree is du(1).

personally, i have a little rc script in my bin called find
(attached), which does almost all of what i used to use find for under
unix, i.e.  find files with a particular name.

e.g.
	find . '\.c$'
to find all c source files.

i've also got a little version of xargs (also attached) that reads
filenames from stdin and occasionally executes a command with those as
arguments, which is useful when grepping in hierarchies where the list
of files will be larger than execv will tolerate (plus you start
getting results sooner).  luckily newlines are illegal in plan 9 names
AFAIK so it's not vulnerable to the same problems as the unix xargs.

so ls -lR becomes:

	find . . | xargs ls -l

  cheers,
    rog.


[-- Attachment #2: find --]
[-- Type: text/plain, Size: 181 bytes --]

#!/bin/rc
if (~ $#* 1 0) {
	echo 'usage: find <dir>... <re>' >[1=2]
	exit usage
}
a=()
while (! ~ $#* 1) {
	a=($a $1)
	shift
}
du -a $a | sed 's/^[^ 	]*[ 	]//' | grep $1

[-- Attachment #3: xargs.c --]
[-- Type: text/plain, Size: 1647 bytes --]

#include <u.h>
#include <libc.h>
#include <bio.h>

char *makeline(void);

#define NUMARGS 470
#define MAXSIZE 5000

void run(char **cmd);
Biobuf stdin;
int main(int argc, char **argv)
{
	char **cmd;
	int i, n, m, size;
	if (argc < 2) {
		fprint(2, "Usage: xargs [cmd args...]\n");
		exits("bad usage");
	}
	if (Binit(&stdin, 0, OREAD) == -1) {
		fprint(2, "couldn't init stdin\n");
		exits("error");
	}
	cmd = malloc((argc - 1 + NUMARGS + 1) * sizeof(char *));
	n = 0;
	for (i = 1; i < argc; i++) {
		cmd[n++] = argv[i];
	}

	for (;;) {
		int eof = 0;;
		size = 0;
		for (m = 0; m < NUMARGS && size < MAXSIZE; m++) {
			if ((cmd[n + m] = makeline()) == 0) {
				eof = 1;
				break;
			}
			size += strlen(cmd[n + m]);
		}
		cmd[n + m] = 0;
		if (m > 0)
			run(cmd);
		for (i = 0; i < m; i++) {
			free(cmd[n+i]);
		}
		if (eof)
			break;
	}
	return 0;
}

int pwait(void)
{
	Waitmsg msg;
	if (wait(&msg) == -1)
		return -1;
	return atoi(msg.pid);
}

void run(char **cmd)
{
	char buf[256];
	int npid, pid = fork();
	if (pid == -1) {
		perror("couldn't fork");
		exits("no forkage");
	}
	if (pid == 0) {
		if (cmd[0][0] != '/' && strncmp(cmd[0], "./", 2)) {
			sprint(buf, "/bin/%s", cmd[0]);
			exec(buf, cmd);
		} else {
			exec(cmd[0], cmd);
		}
		perror(cmd[0]);
		exits("no exec");
	}
	while ((npid = pwait()) != pid && npid != -1)
		;
}

char *makeline(void)
{
	char *ln, *ret;
	int len;
	if ((ln = Brdline(&stdin, '\n')) == 0) {
		return 0;
	}
	len = Blinelen(&stdin);
	ret = malloc(len + 1);
	memcpy(ret, ln, len);
	ret[len-1] = '\0';
	return ret;
}

^ permalink raw reply	[flat|nested] 53+ messages in thread

end of thread, other threads:[~2008-07-18 13:22 UTC | newest]

Thread overview: 53+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-07-17 22:56 [9fans] sam question Skip Tavakkolian
2008-07-18  0:28 ` erik quanstrom
2008-07-18  0:45   ` Pietro Gagliardi
2008-07-18 10:01     ` roger peppe
2008-07-18 13:22       ` Russ Cox
  -- strict thread matches above, loose matches on Subject: below --
2001-08-20 12:06 [9fans] Sam question bwc
2001-08-19 18:06 rob pike
2001-08-19 15:05 bwc
2001-08-19 15:59 ` Boyd Roberts
2001-08-19 12:44 rob pike
2001-08-18  7:38 nigel
2001-08-18  8:31 ` Steve Kilbane
2001-08-20  8:57   ` Luis Fernandes
2001-08-20 11:10     ` Boyd Roberts
2001-08-18 11:06 ` Boyd Roberts
2001-08-19  6:57 ` Lucio De Re
2001-08-19 10:54   ` Boyd Roberts
2001-08-19 11:13     ` Lucio De Re
2001-08-19 12:02       ` Boyd Roberts
2001-08-19 12:23         ` Lucio De Re
2001-08-19 16:17           ` Steve Kilbane
2001-08-19 20:57 ` Dan Cross
2001-08-17 22:35 David Gordon Hogan
2001-08-18  4:47 ` Rick Hohensee
2001-08-19  6:29 ` Lucio De Re
2001-08-17 22:22 geoff
2001-08-17 17:00 rob pike
2001-08-17 16:32 David Gordon Hogan
2001-08-17 16:55 ` Lucio De Re
2001-08-17 17:08   ` Boyd Roberts
2001-08-17 17:28   ` Louis Beleos
2001-08-17 17:45     ` Lucio De Re
2001-08-17 17:04 ` Boyd Roberts
2001-08-17 17:04 ` Steve Kilbane
2001-08-18  1:36   ` Boyd Roberts
2001-08-19  6:31     ` Lucio De Re
2001-08-17 14:22 rob pike
2001-08-17 14:15 rob pike
2001-08-17 16:58 ` Boyd Roberts
2001-08-20  8:56 ` Douglas A. Gwyn
2001-08-14 12:41 rob pike
2001-08-08 10:45 [9fans] ls -R rog
2001-08-08 17:08 ` [9fans] Sam question gene garbutt
2001-08-14  9:44   ` Douglas A. Gwyn
2001-08-16 21:07     ` Boyd Roberts
2001-08-17  8:50       ` Douglas A. Gwyn
2001-08-17 12:14         ` Boyd Roberts
2001-08-20  8:56           ` Douglas A. Gwyn
2001-08-20 11:11             ` Boyd Roberts
2001-08-20 16:25             ` Sam Ducksworth
2001-08-20 15:11               ` Boyd Roberts
2001-08-21  8:37                 ` Ozan Yigit
2001-08-21  9:31                   ` Boyd Roberts
2001-08-22  2:52                     ` Donald Brownlee

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).