Hi,
If Erik's fix works for Lyle's installation, I suggest that you
include it in the distribution.
Greetings: Bela (the annoying "include it in the distrib" guy)
> one last kick of a dead horse: see that's exactly what I'm
> talking about -- all these exceptions and for what? I'm
> pretty sure if we change the devpipe today not to send
> a note nobody would even notice...
since you're confident that this exception is spurious,
why don't you remove it from
On Jul 19, 2009, at 2:55 PM, Charles Forsyth wrote:
not for network connections?
i think pipe is the only case, and even that is suppressed
for pipes that carry 9p, after mounting.
one last kick of a dead horse: see that's exactly what I'm
talking about -- all these exceptions and for what? I
On Jul 19, 2009, at 2:01 PM, Francisco J Ballesteros wrote:
Bescause consumers produce pipeline results why
producers do not?
ls | wc > /tmp/nfiles
I want nfiles to be ok.
however
ls | date
should probably let ls die as soon as date completes
True. However, you'd get the same result if wri
Hi,
Is there some way to access command line arguments with squint? The
provided paper and squint/sq don't mention any method of passing
options to scripts.
... better yet: is there a simple/minimal editor that doesn't require
learning a command language to begin using it first?
Nope. Learn ed(1). It's really very simple to use.
The advantage of Acme is that there isn't much learning: all the commands
are obvious (eg Put writes back to disk), but you do have to learn the mouse
clicks to execute them.
I use sed's language constantly, and look forward to expanding my bag of
tricks with sam. Stream editors are without-a-dou
On Sunday 19 July 2009 19:12:50 Skip Tavakkolian wrote:
> > The few minutes spent learning ed(1) will be well repaid. You'll be
> > one of the smartest guys on your block.
>
> i second that. learning it has been one of the best investments of my
> time since 1982.
>
I would say the same thing a
> The few minutes spent learning ed(1) will be well repaid. You'll be
> one of the smartest guys on your block.
i second that. learning it has been one of the best investments of my
time since 1982.
On Sun, 19 Jul 2009 14:05:04 -0400
erik quanstrom wrote:
> On Sun Jul 19 12:26:24 EDT 2009, eeke...@fastmail.fm wrote:
> > I was never satisfied with dircp. It's practice of copying the contents
> > of one directory into another seemed limiting at best, obstructive at
> > worst. The recursive cop
On Sunday 19 July 2009 16:25:18 John Floren wrote:
> Run 9fat: first, then run acme in the same window. Or, run acme, then
> do the command "Local 9fat:" inside the editor.
>
On Sunday 19 July 2009 16:28:35 Federico G. Benavento wrote:
> cp plan9.ini plan9.ini.old
>
> acme didn't see /n/9fat/plan9.
> Run 9fat: first, then run acme in the same window. Or, run acme, then
> do the command "Local 9fat:" inside the editor.
in rio, i prefer to plumb the string "Local 9fat:". this
means that all new windows will inherit /n/9fat in their
namespaces.
- erik
cp plan9.ini plan9.ini.old
acme didn't see /n/9fat/plan9.ini because the 9fat partition wasn't
mounted in its namespace.
On Sun, Jul 19, 2009 at 8:19 PM, Corey wrote:
> On Sunday 19 July 2009 16:02:20 John Floren wrote:
>> On Sun, Jul 19, 2009 at 3:51 PM, Corey wrote:
>
>> > Can someone give me
On Sun Jul 19 19:30:10 EDT 2009, benave...@gmail.com wrote:
> cp plan9.ini plan9.ini.old
8.3, remember.
- erik
On Sun, Jul 19, 2009 at 4:19 PM, Corey wrote:
> On Sunday 19 July 2009 16:02:20 John Floren wrote:
>> On Sun, Jul 19, 2009 at 3:51 PM, Corey wrote:
>
>> > Can someone give me just the bare minimal sam command/info that I need
>> > to:
>> >
>> > edit a couple lines
>> > close and save properly
>> >
On Sunday 19 July 2009 16:02:20 John Floren wrote:
> On Sun, Jul 19, 2009 at 3:51 PM, Corey wrote:
> > Can someone give me just the bare minimal sam command/info that I need
> > to:
> >
> > edit a couple lines
> > close and save properly
> >
> You can use acme if you want.
>
That was my first eff
On Sunday 19 July 2009 16:04:05 Brantley Coile wrote:
> The few minutes spent learning ed(1) will be well repaid. You'll be
> one of the smartest guys on your block.
>
Yes, however I simply want to put off that learning, from: _right_this_moment_,
to: _after_my_box_is_online_.
On Sun, Jul 19, 2009 at 3:51 PM, Corey wrote:
>
> Ok, so I have my fossil+venti and hopefully soon-to-be cpu and auth-server
> booted up for the first time, and I'm in rio as user glenda.
>
> I'm continuing to follow the docs, which is prompting me to edit plan9.ini for
> various things.
>
> sam is
The few minutes spent learning ed(1) will be well repaid. You'll be
one of the smartest guys on your block.
iPhone email
On Jul 19, 2009, at 6:51 PM, Corey wrote:
Ok, so I have my fossil+venti and hopefully soon-to-be cpu and auth-
server
booted up for the first time, and I'm in rio as u
acme
Ok, so I have my fossil+venti and hopefully soon-to-be cpu and auth-server
booted up for the first time, and I'm in rio as user glenda.
I'm continuing to follow the docs, which is prompting me to edit plan9.ini for
various things.
sam is completely opaque to the uninitiated. (I'm a mere vi fanat
>not for network connections?
i think pipe is the only case, and even that is suppressed
for pipes that carry 9p, after mounting.
On Sun, Jul 19, 2009 at 10:30:41AM +0100, Charles Forsyth wrote:
> >perhaps i've been asleep at the swtch, but i don't recall seing writes
> >on closed channels terminate programs with a note.
>
> sys: write on closed pipe
>
> mainly to kill off a pipeline when the thing at the end has finished.
Bescause consumers produce pipeline results why
producers do not?
ls | wc > /tmp/nfiles
I want nfiles to be ok.
however
ls | date
should probably let ls die as soon as date completes
>
> Why inequality?
>
> Thanks,
> Roman.
>
>
>
On Jul 19, 2009, at 2:30 AM, Charles Forsyth wrote:
perhaps i've been asleep at the swtch, but i don't recall seing
writes
on closed channels terminate programs with a note.
sys: write on closed pipe
mainly to kill off a pipeline when the thing at the end has finished.
i think that might be
> Observe:
>
also observe (as ron noted) this happens mostly on
pipes. this would tend to cause pipes to shutdown
from right to left.
; 8c -FVTw roman.c && 8l -o roman roman.8
; {roman | dd >/dev/null} & sleep 7; slay dd|rc
write good
write good
; note: sys: write on closed pipe pc=0x270a
w
On Jul 18, 2009, at 6:06 PM, erik quanstrom wrote:
On Sat Jul 18 14:41:02 EDT 2009, r...@sun.com wrote:
In the "mom, why sky is blue" department, here's a silly question:
is there any good reason that read(2) on a hangup channel returns
an error, while write(2) on a hangup channel terminates an
<{echo +}
works just fine.
On Sun, Jul 19, 2009 at 8:16 PM, Richard Miller<9f...@hamnavoe.com> wrote:
>> i keep /tmp/allproto around with the contents of '+'.
>
> There's also one in /sys/lib/sysconfig/proto/allproto,
> but that takes longer to type.
>
>
>
> i keep /tmp/allproto around with the contents of '+'.
There's also one in /sys/lib/sysconfig/proto/allproto,
but that takes longer to type.
On Sun Jul 19 12:26:24 EDT 2009, eeke...@fastmail.fm wrote:
> I was never satisfied with dircp. It's practice of copying the contents
> of one directory into another seemed limiting at best, obstructive at
> worst. The recursive copy options of Gnu cp seemed much more elegant(!),
> preserving the u
I was never satisfied with dircp. It's practice of copying the contents
of one directory into another seemed limiting at best, obstructive at
worst. The recursive copy options of Gnu cp seemed much more elegant(!),
preserving the usual option syntax of cp and merely extending it slightly
to include
On Sun, Jul 19, 2009 at 5:46 PM, wrote:
> http://www.beyondlogic.org/usbnutshell/usb6.htm#SetupPacket
>
IIRC, I think the host controller is responsible for timing out
requests sent to the device (I refer to setup packets), but my uchi
does not. In any case, I don't think anyone wants to remove t
http://www.beyondlogic.org/usbnutshell/usb6.htm#SetupPacket
--
cinap
--- Begin Message ---
that's what I understood.
In any case I'll run the code through all devices I have before
sending any usb patch. I'm still not sure that some disks currently
working won't cease working if they do their own
> Normal read/write system call doesn't
>> have a timeout argument.
>
> do you mean "normal read/write" vs. an rpc protocol, say, like
> /dev/sdXX/raw?
No, I meant "normal read/write" vs more complicated things like select()
in other operating systems.
that's what I understood.
In any case I'll run the code through all devices I have before
sending any usb patch. I'm still not sure that some disks currently
working won't cease working if they do their own timeouts. I just
want to be sure.
I placed timeouts there only when I found uncooperative
> > isn't it easier to set
> > up time timeout at the beginning?
>
> Not if you use normal read/write to talk to usb endpoints (which
> seems to me a Good Thing). Normal read/write system call doesn't
> have a timeout argument.
do you mean "normal read/write" vs. an rpc protocol, say, like
/dev
> aren't there device types
> that take timeouts in their requests?
There might be, but if so, that's the business of the device's
own driver, not the usb driver.
> isn't it easier to set
> up time timeout at the beginning?
Not if you use normal read/write to talk to usb endpoints (which
seems
> sd doesn't deal with this problem. for example, currently most
> of the sd devices (orion is an exception) are uninterruptable.
> and you get whatever timeout you get.
>
> the sticky bit is that scsi and ata devices implement timeouts
> on the devices. these might not always be appropriate and
On Sun Jul 19 07:53:33 EDT 2009, 9f...@hamnavoe.com wrote:
> > I think it's better to remove the timeout from bulk endpoints (perhaps by
> > making it optional)
>
> There's already a general way to time out any read/write operation
> alarm() and notify(). Why add a special case option for one par
On Sat, 18 Jul 2009 22:40:14 +0200
Adriano Verardo wrote:
> Unbelievable but true, a driver (or a patch to a driver or whatever
> else) done by an
> italian is not considered as good as the stuff from the original site.
> It is a psychological problem I have often to face with.
Open-source
> There's already a general way to time out any read/write operation
> alarm() and notify(). Why add a special case option for one particular
> type of file? I would say just remove it.
>
You're right.
I'll do so.
> I think it's better to remove the timeout from bulk endpoints (perhaps by
> making it optional)
There's already a general way to time out any read/write operation
alarm() and notify(). Why add a special case option for one particular
type of file? I would say just remove it.
>
> I strongly a
> other end has something to send. Have you seen anything in the USB
> spec which indicates a timeout for reading from a bulk pipe is
> appropriate?
>
No. All devices I had tested at that time required a time out.
Ethernet came later.
I think it's better to remove the timeout from bulk endpoints
disconnecting a usb device should result (eventually)
in a suitable status on the relevant hub, and thus
shouldn't require a timeout to get an error back to the user.
devices that don't respond because they are in a bad
state can be unplugged (if removeable).
built-in devices on built-in hubs tha
> THere are some disks that do not respond
> to the controller after they crash. Also, RPCs carrying ctl requests
> to the devices
> may not respond either in some devices. I thought it was for sure
> an error when control and bulk requests took more than a while.
Bulk pipes are not always used in
>perhaps i've been asleep at the swtch, but i don't recall seing writes
>on closed channels terminate programs with a note.
sys: write on closed pipe
mainly to kill off a pipeline when the thing at the end has finished.
i think that might be the only instance where a note is used.
THere are some disks that do not respond
to the controller after they crash. Also, RPCs carrying ctl requests
to the devices
may not respond either in some devices. I thought it was for sure
an error when control and bulk requests took more than a while.
Right now I´m not so sure regarding bulk tr
pulling the device gets me a "crc/timeout error", not a
"request timed out".
but i'm not sure if this is always the case though.
the driver should not artificially generate errors in
my opinion even if it would be convinient for some
userspace drivers to have it. those who need a timeout
should c
The only justification I can see is to disconnect to stuff that's been
unplugged or misbehaves.
In your case that's not true.
brucee
On Sun, Jul 19, 2009 at 5:16 PM, wrote:
> from the manpage:
>
> For control, bulk, and isochronous transfers, there is an
> implicit timeout per
from the manpage:
For control, bulk, and isochronous transfers, there is an
implicit timeout performed by the kernel and it is not nec-
essary for applications to place their own timers. For
interrupt transfers, the kernel will not time out any opera-
50 matches
Mail list logo
