Re: [9fans] Sam question

Re: [9fans] Sam question

[rob pike]

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

Re: [9fans] Sam question

[Boyd Roberts]

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

sure is.

Re: [9fans] Sam question

[Douglas A. Gwyn]

rob pike wrote:
> 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.

I agree that it's "old-think", but that's appropriate
since retab's main use is to present a display of an
"old" document in the manner intended/assumed by the
document's creator.  (The four main environments I've
encountered have been: every 8th column, every 5th
column, every 4th column, and no tab support at all.)

Obviously, the need for such a tool suggests that the
original environmental assumptions were a bad idea.

[9fans] sam question

[Skip Tavakkolian]

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?

Re: [9fans] sam question

[erik quanstrom]

> 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?

no they don't: sam/regexp.c and acme/regx.c both have a lex function
that starts basically like this (from acme)

int
lex(void){
	int c;

	c = *exprp++;
	switch(c){
	case '\\':
		if(*exprp)
			if((c= *exprp++)=='n')
				c='\n';

i suppose you could also type <compose>000d.

- erik

Re: [9fans] sam question

[Pietro Gagliardi]

On Jul 17, 2008, at 8:28 PM, erik quanstrom wrote:
> i suppose you could also type
ctl+m

Re: [9fans] sam question

[roger peppe]

On Fri, Jul 18, 2008 at 1:45 AM, Pietro Gagliardi <pietro10@mac.com> wrote:
> On Jul 17, 2008, at 8:28 PM, erik quanstrom wrote:
>> i suppose you could also type
>
> ctl+m

interestingly this only works in some versions of acme and sam.
it seems to work ok under plan 9, and in inferno's acme,
but not in p9p or acme sac.

Re: [9fans] sam question

[Russ Cox]

> interestingly this only works in some versions of acme and sam.
> it seems to work ok under plan 9, and in inferno's acme,
> but not in p9p or acme sac.

There are two different issues here.  One is getting
an actual \r to the program in question (acme, sam, etc.)
and the second is how that program interprets it.

The first issue is getting a \r to the program.
On most systems, you type \r.  On Windows,
Enter sends \r so the keyboard handler swaps \r and \n,
so you type Ctl-J to get \r.  (If anyone cared, I think
you could check for Ctl in the input handler and not
swap in that case.)  This applies to drawterm, inferno,
and 9pm, which all share the same gui code (I think 9pm
is the progenitor).

The second issue is what the program thinks \r is.
There's a long, boring history of Plan 9 coming to
grips with the many extra keys on the PC keyboard,
but the short version is that for a long time the End key's
only use was to generate \r.  That era ended in
December 2003, around the time rio, sam, and acme
started using Home, End, PgUp, and PgDown for
scrolling.  Unfortunately, the p9p keyboard.h didn't
get the memo, and it was still using \r as End.
This meant that when you typed Ctl-M acme or sam
saw End (and probably didn't scroll because you were
in a window with little text).  I just fixed this in p9p
cvs and hg.  (I had always chalked it up to an X11 input
issue similar to the Windows one, or I'd have gone
looking for it years ago.)

I can't explain why acme sac doesn't handle \r right,
but now you know where to look.

Russ

Re: [9fans] Sam question

[bwc]

[-- 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

Re: [9fans] Sam question

[rob pike]

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

-rob

Re: [9fans] Sam question

[bwc]

> 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

Re: [9fans] Sam question

[Boyd Roberts]

From: <bwc@borf.com>
> 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'.

have you ever read the code to namei()?

goto is there because it was/is needed.

Re: [9fans] Sam question

[rob pike]

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

False.

-rob

Re: [9fans] Sam question

[nigel]

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.

Re: [9fans] Sam question

[Steve Kilbane]

Nigel:

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

Exactly my point. Put any two programmers together, and they'll find
*something* they can disagree on, for layout. It's a holy war issue that'll
never be completely solved, so why worry? Get them to write better code,
instead.

steve

Re: [9fans] Sam question

[Luis Fernandes]

>>>>> "steve" == Steve Kilbane <steve@whitecrow.demon.co.uk> writes:

    steve> Exactly my point. Put any two programmers together, and
    steve> they'll find *something* they can disagree on, for
    steve> layout. It's a holy war issue that'll never be completely
    steve> solved, so why worry?

Well, what if there was an editor that re-displayed the code (braces,
tabs, everything) in the exact manner you preferred, regradless of
it's structure in the actual file? Then everyone could have their
very own One True Brace Style and One True Tab Setting.  Wouldn't
that put an end to the holy wars?

I once proposed this idea to Barry Warsaw, the author of C-mode for
Emacs, and IIRC he said it wasn't worth the effort.

Re: [9fans] Sam question

[Boyd Roberts]

> I once proposed this idea to Barry Warsaw, the author of C-mode for
> Emacs, and IIRC he said it wasn't worth the effort.

sounds like a good call and from an emacs head too -- amazing.

Re: [9fans] Sam question

[Boyd Roberts]

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

very necessary when hacking the 7th ed's shell's shellgol.

Re: [9fans] Sam question

[Lucio De Re]

On Sat, Aug 18, 2001 at 08:38:31AM +0100, nigel@9fs.org wrote:
> 
> So use more columns! When did you last use a VT100?
> 
All the time, in emulation at least :-(

Encouraging wider lines has the drawback that my ceiling may
well be your floor.  So how do we communicate?

As Boyd aptly pointed out, readability should come very high in
the priorities.  I'll even accept "continue", "break", "return"
and "exit()" as compromises for the sake of readability.  I
_do_ draw the line at "goto".

++L

Re: [9fans] Sam question

[Boyd Roberts]

From: "Lucio De Re" <lucio@proxima.alt.za>
> I _do_ draw the line at "goto".

well it's a toolkit.  sometimes you have to use 'goto' for clarity,
much as i am loathed to.  usually a:

    for (;;)
    {
        for (;;)
        {
            ...

            if (forbid(c))
                goto break2;

            ...
        }
    }

break2:

the problem being that at the end of the first loop requires
some sort of test (probably the same test as in the second
loop) which will cause code duplication and one day you will
forget to keep both tests in sync.

iirc it should be 'goto fonfon' :)

Re: [9fans] Sam question

[Lucio De Re]

On Sun, Aug 19, 2001 at 12:54:18PM +0200, Boyd Roberts wrote:
> 
> well it's a toolkit.  sometimes you have to use 'goto' for clarity,
> much as i am loathed to.  usually a:
> 
I believe "goto" was retained in C for the benefit of code
generators.

The alternative to "goto" in your instance is actually (almost)
obvious from your explanation ;-)  You need the duplicate test
to check a condition that will not change with changed
circumstances, for example a variable set earlier or a
function.  The redundancy is unavoidable, at the end of a
search you still need to know if you succeeded or failed:

	while (!finished && !found) {
	}
	if (finished) {
	} else { // found!
	}

Sorry to teach you to suck eggs, I'm sure I'm not telling you
anything new :-)  On the other hand, I'd love a language where
the above can be represented elegantly (for some value of
elegantly, and SNOBOL doesn't count :-)

++L

PS: Try/Catch in C++ addresses this out-of-band behaviour, Tcl
uses "uplevel" and all round it does cry out for a clean
solution.  But I think it is quite intractable in linear
languages and the human intellect balks at coding in two
dimensions (or is it two-dimensional what we do and three-
dimensional would be too hard?).

Re: [9fans] Sam question

[Boyd Roberts]

> Sorry to teach you to suck eggs, I'm sure I'm not telling you
> anything new :-)

the trouble is that the mess you are trying to get out of may
be extremely inelegant to test for at the end of the outer loop.

it's usually error cases that screw things up and destroy perfectly
good loops.

Re: [9fans] Sam question

[Lucio De Re]

On Sun, Aug 19, 2001 at 02:02:44PM +0200, Boyd Roberts wrote:
> 
> the trouble is that the mess you are trying to get out of may
> be extremely inelegant to test for at the end of the outer loop.
> 
> it's usually error cases that screw things up and destroy perfectly
> good loops.
> 
Agreed.  And it isn't always feasible to test in advance,
although even when it is, one may inherit a previous pile of
spaghetti.

With errors (I like to think of them as contingencies), one
knows something may go wrong, but not what, only the effects
can be identified (an NFS service is unmounted, or a file is
corrupt, whatever).  The "try/catch" approach makes sense, but
a clean (nevermind elegant) implementations would have to pass
a lot of criticism.  Yet the alternative is the dreaded "goto"
- better the devil you know syndrome?

Hm, the other contributing factor is the lifetime of code.  One
never expects prototyping code to be still running 20 years
later, yet I doubt there's much that is proper
production-quality code out there.  If one profiled code for a
while, the uncertainty in the middle of a loop would eventually
turn into predictable events and the "goto"s could be replaced
with precondition testing.  But who profiles prototypes?

++L

Re: [9fans] Sam question

[Steve Kilbane]

> The "try/catch" approach makes sense, but
> a clean (nevermind elegant) implementations would have to pass
> a lot of criticism.

Except that breaking out of several loops can be normal program
behaviour, rather than an error condition. It's not out-of-bounds,
necessarily.

> Yet the alternative is the dreaded "goto"

Not really. Being able to name loops and exit or continue a
particular nesting loop is a safe middle ground - it just
happens to be missing from C. There's inner-loop-only, and
there's goto-anywhere-in-this-function, which is a shame.

steve

Re: [9fans] Sam question

[Dan Cross]

In article <E15Y0gh-000N2j-0U@anchor-post-30.mail.demon.net> you write:
>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?

Probably six years ago (really!), but I did use a laser printer on
Friday.

One reason the 80 column limit still makes sense is that one can print
the code out with a minimum of hassle (no special pretty printers or
whatever) and it'll be readable enough to review.

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

I think it's the, ``within bounds'' part that throws so many people
off.  Things like ``Hungarian notation'' just tend to obscure a program,
and even though my company's coding standards specifically ban it,
the windows programmers put it in anyway.  How terribly frustrating.

I agree that consistency is important, but consistent unreadable garbage
isn't too helpful.

Something I've noticed is that programmers who don't take the time
and care to produce a *readable* program are the ones who write bad
software.  Someone who actually puts some effort into the presentation
is, in my experience, more likely to produce a correct, working and
maintainable program than someone who doesn't.

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

Sure, as long as the local dialect is reasonable, or should I say
readable?  :-)

	- Dan C.

Re: [9fans] Sam question

[David Gordon Hogan]

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

Re: [9fans] Sam question

[Rick Hohensee]

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

Very interesting, since I don't use continue myself that I can recall. The
above technique is limited to "trailing ifs" though isn't it? i.e. it
won't work with...


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

i.e. where the if to continuefy is not the last thing in the enclosing
block? 

Rick Hohensee
							www.clienux.com

Re: [9fans] Sam question

[Lucio De Re]

On Fri, Aug 17, 2001 at 06:35:27PM -0400, David Gordon Hogan wrote:
> 
> Another common reason is that people don't know how to use continue.
> Eg, instead of writing:
> 
In my opinion, "continue" is a marginally restrained "goto", but
then that makes the "switch" statement a veritable abortion,
requiring the even worse "break" everywhere, so perhaps I'd better
not whine about it, at least not in _this_ forum.

++L

Re: [9fans] Sam question

[geoff]

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

Re: [9fans] Sam question

[rob pike]

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

-rob

Re: [9fans] Sam question

[David Gordon Hogan]

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

Re: [9fans] Sam question

[Lucio De Re]

On Fri, Aug 17, 2001 at 12:32:11PM -0400, David Gordon Hogan wrote:
> 
> 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).
> 
Good grief!  We're a long way from my FORTRAN days of being
allowed only capital letters!

I still find it hard to deal with editors that do not allow me
to specify the size of a TAB expansion (SAM?!).  And indenting
by eight zero-wide characters gets you wrapping around eighty
zero-wide columns pretty quickly.  So I fear I'm one of those
who make you sick, I resort to converting all tabs to spaces as
soon as I inherit a different style and I have to use SAM on
it.

> Real programmers indent with tabs.
> 
My "trim" utility will convert spaces to tabs and viceversa (I
wrote it to remove trailing spaces left by an evil DOS editor that
confused the RM-COBOL compiler) and understands variable spacing
tabs, as applicable to the same COBOL, as a variation from fixed
tab sizes.

For a long time, it annoyed me that it preferred a single tab to
a single space, but since I inverted that I'm not sure it wasn't
the right choice.

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

For me, the worst is not being able to tell whether a character
is a space or a tab when it may matter (like inside quotes).

++L

Re: [9fans] Sam question

[Boyd Roberts]

> For me, the worst is not being able to tell whether a character
> is a space or a tab when it may matter (like inside quotes).

it _must_ be a \t, but i've seen all sorts of broken code that
uses raw tab characters -- therein lies madness.

Re: [9fans] Sam question

[Louis Beleos]

Lucio De Re wrote:
>  [...]
> I still find it hard to deal with editors that do not allow me
> to specify the size of a TAB expansion (SAM?!).  [...]
> 
> ++L

Have you tried setting /env/tabstop to your preferred value?

--Louis

Re: [9fans] Sam question

[Lucio De Re]

On Fri, Aug 17, 2001 at 10:28:39AM -0700, Louis Beleos wrote:
> 
> Lucio De Re wrote:
> >  [...]
> > I still find it hard to deal with editors that do not allow me
> > to specify the size of a TAB expansion (SAM?!).  [...]
> > 
> > ++L
> 
> Have you tried setting /env/tabstop to your preferred value?
> 
As Rob points out, I'm one of old-thinker, ... or whiner.  I have
no doubt even used the facility, but I mostly, wrongly, think that
SAM doesn't do tabs properly.  Senility, maybe.

Or having used too many editors, from the editor built into
GW-Basic, the one in Wang's Basic-2, EDLIN and the DOS command
line, MS-DOS's EDIT, and the saga continues to this day, with
the syntax highlighting tools like the editor supplied with the
second edition Inferno (ED4W).

To be perfectly honest, my romantic notions are that nothing
beats the second release of Brief, although I now don't
remember if it had C or Lisp-like programming syntax.  Of
course, that was in the days of typescripts only, at least on
the computers I had access to.

I imagine editors are very much subjective tools and at best we
can compare notes, not evangelise.

++L

Re: [9fans] Sam question

[Boyd Roberts]

> Real programmers indent with tabs.

yup

Re: [9fans] Sam question

[Steve Kilbane]

dhog wrote:
> I am SO sick of C programs that are indented using spaces,

...whereas I'm fairly bored with people being obsessed with
indentation, bracing style, whatever. It's the non-whitespace
bits that count, and they're usually in far greater need of
correction.

steve

Re: [9fans] Sam question

[Boyd Roberts]

From: "Steve Kilbane" <steve@whitecrow.demon.co.uk>
> It's the non-whitespace
> bits that count, and they're usually in far greater need of
> correction.

if you can't read it it's gonna be hard to fix it.

Re: [9fans] Sam question

[Lucio De Re]

On Sat, Aug 18, 2001 at 03:36:44AM +0200, Boyd Roberts wrote:
> 
> From: "Steve Kilbane" <steve@whitecrow.demon.co.uk>
> > It's the non-whitespace
> > bits that count, and they're usually in far greater need of
> > correction.
> 
> if you can't read it it's gonna be hard to fix it.
> 
If "indent" could do its job properly, this entire discussion
would be totally moot.

++L

Re: [9fans] Sam question

[rob pike]

> 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

Re: [9fans] Sam question

[rob pike]

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

[9fans] ls -R

[rog]

[-- 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;
}

[9fans] Sam question

[gene garbutt]

I am a sam newbie and have a quick question for the experts...

How would I remove backspaces from a file? Or search for a backspace in a
file?

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?

Thanks,
Gene Garbutt
ggarbutt@earthlink.net

Re: [9fans] Sam question

[Douglas A. Gwyn]

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.

Re: [9fans] Sam question

[Boyd Roberts]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
> > 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.

yup, that's how i do it.  same deal with blowing away cr's.

anyone like to blow away tabs on any given windows app?

Re: [9fans] Sam question

[Douglas A. Gwyn]

Boyd Roberts wrote:
> anyone like to blow away tabs on any given windows app?

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:

NAME
     retab - detab|entab utility

SYNOPSIS
     retab [ [ -io ] global_options ] [ -i input_options ]  [  -o
     output_options ]

DESCRIPTION
     Retab reformats text containing combinations of  spaces  and
     tabs  in accordance with user-specified input and output tab
     stops; trailing spaces and tabs are removed.  Retab is suit-
     able for use as a filter or as a stand-alone utility.

     Options following -i apply to the input text; those  follow-
     ing -o apply to the output text; all others, including those
     following -io, apply to both input and output.  Options  may
     consist  of  a filename (standard input or output used if no
     file specified) and/or tab stop specifications.   Tab  stops
     are  specified  as  a  list  of column numbers (the leftmost
     print position is column # 1)  optionally  followed  by  the
     increment  of  a  regularly-spaced  series of stops past the
     last explicitly given column number; the increment is speci-
     fied  in the form +n.  Unspecified input or output tab stops
     are assumed to be UNIX standard (equivalent to specifying  9
     +8).

EXAMPLE
          $ retab -i foo -o +5
     interprets the tab settings in file ``foo'' according to the
     standard  eight-column  spacing while printing on a terminal
     having hardware stops set in every fifth column.

SEE ALSO
     newform(1).

DIAGNOSTICS
     In case of malfunction, retab terminates with an error  mes-
     sage and returns non-zero exit status.

AUTHOR
     Douglas A. Gwyn, BRL/VLD-VMB

Re: [9fans] Sam question

[Boyd Roberts]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
> Boyd Roberts wrote:
> > anyone like to blow away tabs on any given windows app?
> 
> I carry around a utility I originally developed at Geotronics
> (early 1980s) called "retab" that transforms ...

i was hinting at the fact that tabs on windows are _special_.

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

Re: [9fans] Sam question

[Douglas A. Gwyn]

Boyd Roberts wrote:
> i was hinting at the fact that tabs on windows are _special_.
> ie. they move you from one field to the next.  a real bugger
>     when you _want_ to type a tab in a dialog box.

Ah, okay.  But when you're filling in a form under the Windows
default model, you're not supposed to be entering tab characters
into text, any more than you're supposed to be entering arrow-key
characters.  It's just an unsuitable model for your application.

I'm not saying the Windows GUI is very good, just that if you
have to deal with it, it must be on its own terms..

Re: [9fans] Sam question

[Boyd Roberts]

> I'm not saying the Windows GUI is very good, just that if you
> have to deal with it, it must be on its own terms..

don't i know it -- <gag>.

Re: [9fans] Sam question

[Sam Ducksworth]

you guys bitch and moan about tab keys and the like. just
think about the poor guy that said, "hey i got an idea a
lets find a way to interface one of our typewriters to this
thing. it will be great! the office people will love it." ;-)

--sam

Re: [9fans] Sam question

[Boyd Roberts]

> it will be great! the office people will love it." ;-)

it was great.  it came out of PARC and the 'office people'
loved it.  pity that xerox didn't.

Re: [9fans] Sam question

[Ozan Yigit]

boyd@fr.inter.net (Boyd Roberts) writes:

> it was great.  it came out of PARC and the 'office people'
> loved it.  pity that xerox didn't.

history of ALTO reduced to a sound byte?

Re: [9fans] Sam question

[Boyd Roberts]

> history of ALTO reduced to a sound byte?

well, i wouldn't want to fill up /n/dump, but i can
see my copy of _fumbling the future_ from here.

Re: [9fans] Sam question

[Donald Brownlee]

> 
> > history of ALTO reduced to a sound byte?
> 
> well, i wouldn't want to fill up /n/dump, but i can
> see my copy of _fumbling the future_ from here.

Too bad fumbling-the-future can't be patented.