Hello,
could anybody tell me what's the meaning of '--' in
grep -n $flags -- $1 *.[Cbchm] /dev/null
?
This I found in Russ Cox's g script.
Thanks
Ruda
see arg(2) for all the details.
-- indicates the end of any options, it ensures that any following
arguments which happen to begin with a minus are not interpreted
as options.
consider the classic question: "how do I remove a file called -z"
-Steve
On Sat, 15 May 2010 15:16:35 +0200
Rudolf Sykora wrote:
> could anybody tell me what's the meaning of '--' in
>
> grep -n $flags -- $1 *.[Cbchm] /dev/null
'--' tells the Plan 9 program argument parser to stop looking for
options. See arg(2).
GNU getopt has the same feature.
Robert Ransom
> '--' tells the Plan 9 program argument parser to stop looking for
> options. See arg(2).
so is it a program dependent feature in the sence that I must know
which program uses arg(2) and which does not?
(E.g that grep uses it but some other command (is there any?) does not?)
Must I read the prog
I don't beleive greps manual page says it writes its output to file descriptor 1
and reaqds from file descriptor zero but it does, as do all conventional (sic)
plan9 programs. Similarly they all use arg(2) to parse their args so they will
all support --; however if you are unsure you could look at
On May 14, 2010, at 9:58 PM, EBo wrote:
I lived in NM for 8 years, I loved it, still do, but ABQ fails the
"transport hub" criterion.
I had lots of complaints about that when we had conferences in
santa fe.
Actually, Santa Fe is a pain to have as a destination for an
international
confe
Here is a refinement of fgb's fine work on a contrib system. I have
taken his ideas a bit further, based on my use of his tools in an
unreliable environment. I was getting quite frustrated as I had
multiple failures in the midst of an install, and seeing the message
'xyz already installed', when it
> If I thought people would actually come, I would see if I could organize
> something in Ouray Colorado.
Do you live in that neck of the woods?
> It is about 300 miles north of Albuquerque
> in the San Juan Mountains. You get there by first flying to Denver,
> Phoenix, or Albuquerque, then c
On May 15, 2010, at 10:12 AM, EBo wrote:
If I thought people would actually come, I would see if I could
organize
something in Ouray Colorado.
Do you live in that neck of the woods?
Yes. There aren't many tech people around here and I think it would
be great to get a group of Plan 9 pe
> consider the classic question: "how do I remove a file called -z"
rm ./-z
On Sat May 15 09:54:25 EDT 2010, rudolf.syk...@gmail.com wrote:
> > '--' tells the Plan 9 program argument parser to stop looking for
> > options. See arg(2).
>
> so is it a program dependent feature in the sence that I must know
> which program uses arg(2) and which does not?
> (E.g that grep us
the one big push for new mexico is spaceport america ... maybe we'd
get to see a test launch :-)
but that's a serious hike from ABQ :-)
ron
I'm on a 802.11g here on my lan in my house, where my cpu/auth server
sits - and drawterm is noticeably slow/laggy. For instance, mousing up/down
the rio menus, and drawing/moving new rio windows, scrolling through large
amounts of text... all produce regular finegrained intermittent delays bef
On Saturday 15 May 2010 2:31:57 Corey wrote:
> I'm on a 802.11g here on my lan in my house, where my cpu/auth server
> sits - and drawterm is noticeably slow/laggy.
Oh yeah - I'm using tcp and not il.
Quite a while back, I recall someone was inquiring whether there was any
documentation/notes available with regards to the process of creating one's
own customized plan 9 iso - or related documentation detailing how the
official iso/distro is built. If I remember correctly, there were a couple
re
> the one big push for new mexico is spaceport america ... maybe we'd
> get to see a test launch :-)
>
> but that's a serious hike from ABQ :-)
True, then we can maybe move the venue to Los Cruses, Truth or
Consequences, or maybe even Hatch (and right about time for the chili
festival) ;-) I kn
As far as I am concerned:
http://9fans.net/archive/2008/05/263
and here's maht's blog entry about it:
http://maht0x0r.blogspot.com/2007/11/roll-your-own-plan9-iso.html
hth,
Mathieu
--- Begin Message ---
Quite a while back, I recall someone was inquiring whether there was any
documentation/notes
On Fri, May 14, 2010 at 7:01 PM, erik quanstrom wrote:
> > > It supposedly has 256K (which seems a lot for this type of app). I
> > > noticed that they provide the Gerber file, schematic and assembly
> diagrams,
> > > and probably everything needed to seriously hack the thing if you
> cannot
> >
I have nupas from a long time back and recently
decided to run
contrib/install quanstro/nupas
However, it seems that the nupas package has
since been moved from nupas to overwrite the base
upas, along with base files in /sys/man, other src
directories (faces, etc.) and some files in /mail/lib.
On Saturday 15 May 2010 2:57:12 Mathieu Lonjaret wrote:
> As far as I am concerned:
> http://9fans.net/archive/2008/05/263
>
> and here's maht's blog entry about it:
> http://maht0x0r.blogspot.com/2007/11/roll-your-own-plan9-iso.html
>
Excellent - thanks! (I believe there was one other sourc
On Sat May 15 19:18:57 EDT 2010, aku...@mail.nanosouffle.net wrote:
> So, how to resolve this mess and finally install the
> nupas package? It'd also be nice if somehow files
> in /mail/lib and other places where installed without
> hassle (though I'd like to keep some custom configs
> there).
fir
If one wants to remove an existing user from the fossil file server,
is it perfectly ok to simply edit /adm/users, as the hostowner user,
directly? Or is it considered better practice to issue users -r/-w via
fossilcons? Or is there effectively no real difference?
On Sat May 15 17:33:49 EDT 2010, co...@bitworthy.net wrote:
> On Saturday 15 May 2010 2:31:57 Corey wrote:
> > I'm on a 802.11g here on my lan in my house, where my cpu/auth server
> > sits - and drawterm is noticeably slow/laggy.
>
>
> Oh yeah - I'm using tcp and not il.
clearly! /dev/draw is
> ... but I'm wondering: why does 9load seem to sometimes suffer
> from apparent regressions in the official iso?
i think the bios calls that the official distribution
supports have been the source of a lot of trouble.
i've been looking into why that might be, but don't
have any answers yet.
- e
here's a different approach.
#!/bin/rc
cd /$objtype/bin
for(i in `{find})
# if(! ~ $i */ape/*) # obviously
if(test -f $i)
if(! ~ `{file $i | sed 's/ /_/g'} *:_rc_executable_file)
if(! grep -s ARGBEG
On Sat May 15 19:56:50 EDT 2010, co...@bitworthy.net wrote:
>
> If one wants to remove an existing user from the fossil file server,
> is it perfectly ok to simply edit /adm/users, as the hostowner user,
> directly? Or is it considered better practice to issue users -r/-w via
> fossilcons? Or is
On Saturday 15 May 2010 4:49:32 erik quanstrom wrote:
> On Sat May 15 17:33:49 EDT 2010, co...@bitworthy.net wrote:
> > On Saturday 15 May 2010 2:31:57 Corey wrote:
> > > I'm on a 802.11g here on my lan in my house, where my cpu/auth server
> > > sits - and drawterm is noticeably slow/laggy.
> >
On Saturday 15 May 2010 5:55:33 erik quanstrom wrote:
> On Sat May 15 19:56:50 EDT 2010, co...@bitworthy.net wrote:
> > If one wants to remove an existing user from the fossil file server,
> > is it perfectly ok to simply edit /adm/users, as the hostowner user,
> > directly? Or is it considered be
On Saturday 15 May 2010 5:25:38 erik quanstrom wrote:
> > ... but I'm wondering: why does 9load seem to sometimes suffer
> > from apparent regressions in the official iso?
>
> i think the bios calls that the official distribution
> supports have been the source of a lot of trouble.
> i've been lo
> Ah... heheh - cleary: because I'm using drawterm and drawterm
> doesn't do IL? (sorry if that's a lame question)
currently, that's up to the host os. and none of the host
oses do. in theory one could send raw packets from dt
directly.
- erik
On Saturday 15 May 2010 6:26:05 erik quanstrom wrote:
> > Ah... heheh - cleary: because I'm using drawterm and drawterm
> > doesn't do IL? (sorry if that's a lame question)
>
> currently, that's up to the host os. and none of the host
> oses do.
>
Of course, that makes sense - thanks!
> So, assuming a non-venti server: when removing users from the fossil
> filesystem, there's no effective difference whether I do so by manually
> editing /adm/users versus fscons: users -r/-w [file] ?
>
> I'm just slowly trying to accumulate "best practices" for my documentation
> efforts.
pers
On Saturday 15 May 2010 6:28:00 erik quanstrom wrote:
> > So, assuming a non-venti server: when removing users from the fossil
> > filesystem, there's no effective difference whether I do so by manually
> > editing /adm/users versus fscons: users -r/-w [file] ?
> >
> > I'm just slowly trying to ac
On Sat, May 15, 2010 at 4:45 PM, erik quanstrom wrote:
> sometimes replica gets in its own way. usually when
> it gets confused, i remove /dist/replica/$x and
> /dist/replica/client/$x* and often remove any potentially
> conflicting files. i suppose it would be better to get
> replica to tell me
hmm... this looks good, you are still using the .iso's
from the existing packages.
using hget makes it faster of course, you could
hget from http://plan9.bell-labs.com/sources/contrib
but that would mean the user/package thing...
centralization sometimes makes things easier.
kudos
On Sat, May 15
I'm thinking about going through another installation, and I'm wondering
whether there's usefulness in undertaking a standalone terminal install
using only kfs rather than fossil? And if so, how is this currently done?
As far as I can tell, I'd want to use Erik's 9atom iso - which seems to
suppo
> This type of situation is why I like the concept of packages that
> never overwrite files in the root file system. To back out you just
> get rid of the package file, reboot --> fixed. I feel we need
> improvement on this score.
the ramfs trick will not work if you have a standard
plan 9 network
I use kfs on a standalone Plan 9 box.
The computer has a 100 MHz CPU with
some 48 MB RAM. fossil hogs all
processing power. kfs on the other hand
is wonderfully stable and low maintenance.
Plus, the code is beautiful.
The install procedure from CD involved
manually going through the install
comma
> I'm thinking about going through another installation, and I'm wondering
> whether there's usefulness in undertaking a standalone terminal install
> using only kfs rather than fossil? And if so, how is this currently done?
there's currently no kfs/cwfs install option. it's only my list of thin
By the way, Ron, in order to sort
this mess out, with the help of
Federico, I essentially carried out
the operations in the install script
of your new package system.
I notice you don't keep a list of
installed file paths in /installed/$i
-- is that something you've
already tried, for maintaining
On Sat, May 15, 2010 at 9:28 PM, Akshat Kumar
wrote:
> I notice you don't keep a list of
> installed file paths in /installed/$i
I do, but the intent is that you bind -a package /, and the
'installed' in there has the
files.
I have this allergy to dropping stuff into / :-)
> Perhaps the file i
The following tells the story:
term% /n/sources/plan9/386/bin/upas/fs -f /imaps/imap.gmail.com
/n/sources/plan9/386/bin/upas/fs: opening /imaps/imap.gmail.com:
imap.gmail.com/imaps:server certificate XXX not
term% upas/fs -f /imaps/imap.gmail.com
upas/fs: opening /imaps/imap.gmail.com: imap.gmail
> I do, but the intent is that you bind -a package /, and the
> 'installed' in there has the
> files.
that won't work unless the differences are at the same
level as the bind, in this case /.
- erik
On Sat, May 15, 2010 at 8:41 PM, Corey wrote:
> On Saturday 15 May 2010 2:57:12 Mathieu Lonjaret wrote:
>> As far as I am concerned:
>> http://9fans.net/archive/2008/05/263
>>
>> and here's maht's blog entry about it:
>> http://maht0x0r.blogspot.com/2007/11/roll-your-own-plan9-iso.html
>>
>
> Exce
On Sun, May 16, 2010 at 1:47 AM, Iruata Souza wrote:
> On Sat, May 15, 2010 at 8:41 PM, Corey wrote:
>> On Saturday 15 May 2010 2:57:12 Mathieu Lonjaret wrote:
>>> As far as I am concerned:
>>> http://9fans.net/archive/2008/05/263
>>>
>>> and here's maht's blog entry about it:
>>> http://maht0x0r
On Sat, May 15, 2010 at 9:39 PM, erik quanstrom wrote:
>> I do, but the intent is that you bind -a package /, and the
>> 'installed' in there has the
>> files.
>
> that won't work unless the differences are at the same
> level as the bind, in this case /.
I already do that today :-)
term% bind -
On 5/16/10, ron minnich wrote:
> On Sat, May 15, 2010 at 9:28 PM, Akshat Kumar
> wrote:
>
>> I notice you don't keep a list of
>> installed file paths in /installed/$i
>
> I do, but the intent is that you bind -a package /, and the
> 'installed' in there has the
> files.
>
> I have this allergy t
On Saturday 15 May 2010 9:23:51 erik quanstrom wrote:
> there's currently no kfs/cwfs install option. it's only my list of things
> to do.
>
Good to know, looking forward to when that's ready!
> remember that kfs != ken's fs
>
Cool thanks: I was indeed under the impression that they were the
> term% /n/sources/plan9/386/bin/upas/fs -f /imaps/imap.gmail.com
> /n/sources/plan9/386/bin/upas/fs: opening /imaps/imap.gmail.com:
> imap.gmail.com/imaps:server certificate XXX not
>
> term% upas/fs -f /imaps/imap.gmail.com
> upas/fs: opening /imaps/imap.gmail.com: imap.gmail.com/imaps:fd out of
On Sat, May 15, 2010 at 9:57 PM, Akshat Kumar
wrote:
> http://9grid.net/rminnich/src/package-tools/install
no, it's not there, as I am not yet satisified with the right way to do this.
>
> - instead, there is a straight dircp.
yes.
> So, is this a thing you're developing personally?
no, wha
On Sat, May 15, 2010 at 7:56 PM, Federico G. Benavento
wrote:
> hmm... this looks good, you are still using the .iso's
> from the existing packages.
not quite. I actually recreate all the .iso's from the proto files in
replica//proto.
The reason is that in some cases, the root/ directories for s
51 matches
Mail list logo
