Discussion:
new toy : w command
(too old to reply)
Gaurang Shastri
2012-07-18 13:40:54 UTC
Permalink
Hi All,

Please find attached the initial implementation of "w" command.

Output after compiling my code with toybox :
{{{
[root at stark toybox-0.3.0]# ./toybox w
USER TTY LOGIN@ FROM
root tty2 Wed Jul 11 18:29:24 2012 ( )
rpmuser pts/1 Wed Jul 11 21:33:15 2012 (43.88.80.109)
rpmuser pts/2 Wed Jul 11 19:23:09 2012 (:0.0)
rpmuser pts/3 Tue Jul 17 20:33:41 2012 (43.88.80.208)
}}}

Dear Rob, let me know your comments if any.

Thanks & Regards,
Gaurang Shastri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120718/35529b25/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w.c
Type: text/x-csrc
Size: 937 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120718/35529b25/attachment.c>
Tim Bird
2012-07-18 18:40:59 UTC
Permalink
Post by Gaurang Shastri
Hi All,
Please find attached the initial implementation of "w" command.
{{{
[root at stark toybox-0.3.0]# ./toybox w
root tty2 Wed Jul 11 18:29:24 2012 ( )
rpmuser pts/1 Wed Jul 11 21:33:15 2012 (43.88.80.109)
rpmuser pts/2 Wed Jul 11 19:23:09 2012 (:0.0)
rpmuser pts/3 Tue Jul 17 20:33:41 2012 (43.88.80.208)
}}}
Here is some feedback:

It is better to provide the patch inline, in the message body, rather than
as an attachment. This allows people to easily respond to individual
parts of the patch by commenting directly in a response e-mail. Comments
can be placed in-line with the submitted code. Also, even though this
is a standalone program submission, it is good to submit as a patch
against the full source, suitable for application with 'patch -p1
<filename.patch'
at the root of the source tree. Please provide future contributions
in this format.

This looks like a good basic start. Can you please change the help
text a bit:

Show who is logged on and when and from where they logged in.

Also, do you plan to implement the WHAT column? I find this is useful
to get an idea of what users are doing on the system.

-- Tim
David Seikel
2012-07-18 21:09:48 UTC
Permalink
On Wed, Jul 18, 2012 at 6:40 AM, Gaurang Shastri
Post by Gaurang Shastri
Hi All,
Please find attached the initial implementation of "w" command.
{{{
[root at stark toybox-0.3.0]# ./toybox w
root tty2 Wed Jul 11 18:29:24 2012 ( )
rpmuser pts/1 Wed Jul 11 21:33:15 2012 (43.88.80.109)
rpmuser pts/2 Wed Jul 11 19:23:09 2012 (:0.0)
rpmuser pts/3 Tue Jul 17 20:33:41 2012 (43.88.80.208)
}}}
It is better to provide the patch inline, in the message body, rather
than as an attachment. This allows people to easily respond to
individual parts of the patch by commenting directly in a response
e-mail. Comments can be placed in-line with the submitted code.
I thought it was generally agreed that attached patches are better
than inlined ones. Inline patches can get mangled to the point where
the patch program fails to actually use them. Attached patches are a
separate item that wont get mangled. Look back in this list you will
see inline patches that had this problem. Having the patch actually
work is more important than the ability to comment on them in place.

In my experience with mailing lists where the patch is sent to the list
by the source code management tool, people usually just quote the
entire patch as one big blob when commenting on it. Even if the patch
is megabytes long, and their response is two or three words.
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120719/0e9359bf/attachment.pgp>
Tim Bird
2012-07-18 21:45:48 UTC
Permalink
Post by David Seikel
Post by Tim Bird
It is better to provide the patch inline, in the message body, rather
than as an attachment. This allows people to easily respond to
individual parts of the patch by commenting directly in a response
e-mail. Comments can be placed in-line with the submitted code.
I thought it was generally agreed that attached patches are better
than inlined ones. Inline patches can get mangled to the point where
the patch program fails to actually use them. Attached patches are a
separate item that wont get mangled. Look back in this list you will
see inline patches that had this problem. Having the patch actually
work is more important than the ability to comment on them in place.
In my experience with mailing lists where the patch is sent to the list
by the source code management tool, people usually just quote the
entire patch as one big blob when commenting on it. Even if the patch
is megabytes long, and their response is two or three words.
Those are some good pros and cons for the different approaches.

I'm coming from a kernel development experience, where inline is
preferred. I'll admit it is a bit of a pain to inline the patch
properly with modern mailers (there always seems to be some kind
of tab replacement, leading or trailing whitespace, or line wrapping
issue that someone's mailer does without their consent and which
mangles the patch.) However, commenting on a single line of
an attached patch is pretty annoying.

I'm hoping the patches here are not megabytes long. That would seem to
defeat the purpose of the project. :-)

This is Rob's project so I guess we should just go with whatever
his preference is.

Rob?
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
Rob Landley
2012-07-19 14:00:46 UTC
Permalink
Post by Tim Bird
Post by David Seikel
Post by Tim Bird
It is better to provide the patch inline, in the message body, rather
than as an attachment. This allows people to easily respond to
individual parts of the patch by commenting directly in a response
e-mail. Comments can be placed in-line with the submitted code.
I thought it was generally agreed that attached patches are better
than inlined ones. Inline patches can get mangled to the point where
the patch program fails to actually use them. Attached patches are a
separate item that wont get mangled. Look back in this list you will
see inline patches that had this problem. Having the patch actually
work is more important than the ability to comment on them in place.
In my experience with mailing lists where the patch is sent to the list
by the source code management tool, people usually just quote the
entire patch as one big blob when commenting on it. Even if the patch
is megabytes long, and their response is two or three words.
Those are some good pros and cons for the different approaches.
I'm coming from a kernel development experience, where inline is
preferred. I'll admit it is a bit of a pain to inline the patch
properly with modern mailers (there always seems to be some kind
of tab replacement, leading or trailing whitespace, or line wrapping
issue that someone's mailer does without their consent and which
mangles the patch.) However, commenting on a single line of
an attached patch is pretty annoying.
if(x->ut_type==7) {
xprintf("\n");
xprintf("%-9.8s",x->ut_user);
xprintf("%-9.8s",x->ut_line);
Works for me...
Post by Tim Bird
I'm hoping the patches here are not megabytes long. That would seem to
defeat the purpose of the project. :-)
The linux kernel rules are all about scaling to huge volumes. This
project is about carefully crafting something small, in the
dorodango/bonsai sense. The kernel guys are trying to make a saturn
rocket and I'm trying to build a ship in a bottle or one of the original
swiss watches.

(I note that one of the many time sinks I've been juggling is
linux-kernel Documentation maintainer, where recent commits to
SubmittingPatches wandered by I had to review. I actually need to get my
kernel.org account back but the hoops you have to jump through now that
they're locking the barn door after the horses escaped is just
ridiculous, and last night's hour of energy after work went to toybox,
and this morning's half hour of time before work is going to toybox
email, and what's left _over_ goes to aboriginal so I can use it to test
toybox...)
Post by Tim Bird
This is Rob's project so I guess we should just go with whatever
his preference is.
Rob?
I care about the code. The submission process is secondary. Even busybox
never quite scaled its development community to the point where patch
flooding was a serious problem and they had to streamline it.

It was a good patch, I merged it. And then I did the cleanup Andre
suggested (although I hadn't read his mail yet when I did it. :)

I actually prefer to merge submissions as-is and then do my cleanups on
top of them for attribution reasons. 2-clause BSD renders ownership
moot, but attribution is very important.

That's actually why I like the "hg export" patches, because then the
metadata says it's from them instead of from me. (I can note it by hand
in the comment, but it's not the same...)
Post by Tim Bird
-- Tim
Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Rob Landley
2012-07-19 14:00:46 UTC
Permalink
Post by Tim Bird
Post by David Seikel
Post by Tim Bird
It is better to provide the patch inline, in the message body, rather
than as an attachment. This allows people to easily respond to
individual parts of the patch by commenting directly in a response
e-mail. Comments can be placed in-line with the submitted code.
I thought it was generally agreed that attached patches are better
than inlined ones. Inline patches can get mangled to the point where
the patch program fails to actually use them. Attached patches are a
separate item that wont get mangled. Look back in this list you will
see inline patches that had this problem. Having the patch actually
work is more important than the ability to comment on them in place.
In my experience with mailing lists where the patch is sent to the list
by the source code management tool, people usually just quote the
entire patch as one big blob when commenting on it. Even if the patch
is megabytes long, and their response is two or three words.
Those are some good pros and cons for the different approaches.
I'm coming from a kernel development experience, where inline is
preferred. I'll admit it is a bit of a pain to inline the patch
properly with modern mailers (there always seems to be some kind
of tab replacement, leading or trailing whitespace, or line wrapping
issue that someone's mailer does without their consent and which
mangles the patch.) However, commenting on a single line of
an attached patch is pretty annoying.
if(x->ut_type==7) {
xprintf("\n");
xprintf("%-9.8s",x->ut_user);
xprintf("%-9.8s",x->ut_line);
Works for me...
Post by Tim Bird
I'm hoping the patches here are not megabytes long. That would seem to
defeat the purpose of the project. :-)
The linux kernel rules are all about scaling to huge volumes. This
project is about carefully crafting something small, in the
dorodango/bonsai sense. The kernel guys are trying to make a saturn
rocket and I'm trying to build a ship in a bottle or one of the original
swiss watches.

(I note that one of the many time sinks I've been juggling is
linux-kernel Documentation maintainer, where recent commits to
SubmittingPatches wandered by I had to review. I actually need to get my
kernel.org account back but the hoops you have to jump through now that
they're locking the barn door after the horses escaped is just
ridiculous, and last night's hour of energy after work went to toybox,
and this morning's half hour of time before work is going to toybox
email, and what's left _over_ goes to aboriginal so I can use it to test
toybox...)
Post by Tim Bird
This is Rob's project so I guess we should just go with whatever
his preference is.
Rob?
I care about the code. The submission process is secondary. Even busybox
never quite scaled its development community to the point where patch
flooding was a serious problem and they had to streamline it.

It was a good patch, I merged it. And then I did the cleanup Andre
suggested (although I hadn't read his mail yet when I did it. :)

I actually prefer to merge submissions as-is and then do my cleanups on
top of them for attribution reasons. 2-clause BSD renders ownership
moot, but attribution is very important.

That's actually why I like the "hg export" patches, because then the
metadata says it's from them instead of from me. (I can note it by hand
in the comment, but it's not the same...)
Post by Tim Bird
-- Tim
Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Rob Landley
2012-07-19 13:43:28 UTC
Permalink
Post by David Seikel
On Wed, Jul 18, 2012 at 6:40 AM, Gaurang Shastri
Post by Gaurang Shastri
Hi All,
Please find attached the initial implementation of "w" command.
{{{
[root at stark toybox-0.3.0]# ./toybox w
root tty2 Wed Jul 11 18:29:24 2012 ( )
rpmuser pts/1 Wed Jul 11 21:33:15 2012 (43.88.80.109)
rpmuser pts/2 Wed Jul 11 19:23:09 2012 (:0.0)
rpmuser pts/3 Tue Jul 17 20:33:41 2012 (43.88.80.208)
}}}
It is better to provide the patch inline, in the message body, rather
than as an attachment. This allows people to easily respond to
individual parts of the patch by commenting directly in a response
e-mail. Comments can be placed in-line with the submitted code.
I thought it was generally agreed that attached patches are better
than inlined ones.
The linux-kernel mailing list has a strong preference for inlined
patches, due to the volume. Personally pretty happy with both.


Inlined patches are easier to reply to, but I find them slightly harder
to apply. Various mail clients are insane and break stuff subtly, and
when I save them I have to strip out header stuff manually to avoid
confusing "patch".

Attached patches I can save to a file, open in mousepad, and cut and
paste back to the composer window. Takes ~20 seconds.
Post by David Seikel
Inline patches can get mangled to the point where
the patch program fails to actually use them. Attached patches are a
separate item that wont get mangled. Look back in this list you will
see inline patches that had this problem. Having the patch actually
work is more important than the ability to comment on them in place.
My preference is actually for "hg export" patches because then they're
automatically attributed to the right person and I don't have to come up
with a description for them, and I'm not tempted to fiddle with the
patch _before_ applying it but do my changes as a separate cleanup pass.

But it's not a strong preference. I'd far rather the patch be A) good
code, B) copied to the list rather than just me personally. The rest is
details.
Post by David Seikel
In my experience with mailing lists where the patch is sent to the list
by the source code management tool, people usually just quote the
entire patch as one big blob when commenting on it.
I don't. :)
Post by David Seikel
Even if the patch
is megabytes long, and their response is two or three words.
I think I set the mailing list up to have something like a 150k message
size limit, but I'd have to go look.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Tim Bird
2012-07-18 21:45:48 UTC
Permalink
Post by David Seikel
Post by Tim Bird
It is better to provide the patch inline, in the message body, rather
than as an attachment. This allows people to easily respond to
individual parts of the patch by commenting directly in a response
e-mail. Comments can be placed in-line with the submitted code.
I thought it was generally agreed that attached patches are better
than inlined ones. Inline patches can get mangled to the point where
the patch program fails to actually use them. Attached patches are a
separate item that wont get mangled. Look back in this list you will
see inline patches that had this problem. Having the patch actually
work is more important than the ability to comment on them in place.
In my experience with mailing lists where the patch is sent to the list
by the source code management tool, people usually just quote the
entire patch as one big blob when commenting on it. Even if the patch
is megabytes long, and their response is two or three words.
Those are some good pros and cons for the different approaches.

I'm coming from a kernel development experience, where inline is
preferred. I'll admit it is a bit of a pain to inline the patch
properly with modern mailers (there always seems to be some kind
of tab replacement, leading or trailing whitespace, or line wrapping
issue that someone's mailer does without their consent and which
mangles the patch.) However, commenting on a single line of
an attached patch is pretty annoying.

I'm hoping the patches here are not megabytes long. That would seem to
defeat the purpose of the project. :-)

This is Rob's project so I guess we should just go with whatever
his preference is.

Rob?
-- Tim

=============================
Tim Bird
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
=============================
Rob Landley
2012-07-19 13:43:28 UTC
Permalink
Post by David Seikel
On Wed, Jul 18, 2012 at 6:40 AM, Gaurang Shastri
Post by Gaurang Shastri
Hi All,
Please find attached the initial implementation of "w" command.
{{{
[root at stark toybox-0.3.0]# ./toybox w
root tty2 Wed Jul 11 18:29:24 2012 ( )
rpmuser pts/1 Wed Jul 11 21:33:15 2012 (43.88.80.109)
rpmuser pts/2 Wed Jul 11 19:23:09 2012 (:0.0)
rpmuser pts/3 Tue Jul 17 20:33:41 2012 (43.88.80.208)
}}}
It is better to provide the patch inline, in the message body, rather
than as an attachment. This allows people to easily respond to
individual parts of the patch by commenting directly in a response
e-mail. Comments can be placed in-line with the submitted code.
I thought it was generally agreed that attached patches are better
than inlined ones.
The linux-kernel mailing list has a strong preference for inlined
patches, due to the volume. Personally pretty happy with both.


Inlined patches are easier to reply to, but I find them slightly harder
to apply. Various mail clients are insane and break stuff subtly, and
when I save them I have to strip out header stuff manually to avoid
confusing "patch".

Attached patches I can save to a file, open in mousepad, and cut and
paste back to the composer window. Takes ~20 seconds.
Post by David Seikel
Inline patches can get mangled to the point where
the patch program fails to actually use them. Attached patches are a
separate item that wont get mangled. Look back in this list you will
see inline patches that had this problem. Having the patch actually
work is more important than the ability to comment on them in place.
My preference is actually for "hg export" patches because then they're
automatically attributed to the right person and I don't have to come up
with a description for them, and I'm not tempted to fiddle with the
patch _before_ applying it but do my changes as a separate cleanup pass.

But it's not a strong preference. I'd far rather the patch be A) good
code, B) copied to the list rather than just me personally. The rest is
details.
Post by David Seikel
In my experience with mailing lists where the patch is sent to the list
by the source code management tool, people usually just quote the
entire patch as one big blob when commenting on it.
I don't. :)
Post by David Seikel
Even if the patch
is megabytes long, and their response is two or three words.
I think I set the mailing list up to have something like a 150k message
size limit, but I'd have to go look.

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
David Seikel
2012-07-18 21:09:48 UTC
Permalink
On Wed, Jul 18, 2012 at 6:40 AM, Gaurang Shastri
Post by Gaurang Shastri
Hi All,
Please find attached the initial implementation of "w" command.
{{{
[root at stark toybox-0.3.0]# ./toybox w
root tty2 Wed Jul 11 18:29:24 2012 ( )
rpmuser pts/1 Wed Jul 11 21:33:15 2012 (43.88.80.109)
rpmuser pts/2 Wed Jul 11 19:23:09 2012 (:0.0)
rpmuser pts/3 Tue Jul 17 20:33:41 2012 (43.88.80.208)
}}}
It is better to provide the patch inline, in the message body, rather
than as an attachment. This allows people to easily respond to
individual parts of the patch by commenting directly in a response
e-mail. Comments can be placed in-line with the submitted code.
I thought it was generally agreed that attached patches are better
than inlined ones. Inline patches can get mangled to the point where
the patch program fails to actually use them. Attached patches are a
separate item that wont get mangled. Look back in this list you will
see inline patches that had this problem. Having the patch actually
work is more important than the ability to comment on them in place.

In my experience with mailing lists where the patch is sent to the list
by the source code management tool, people usually just quote the
entire patch as one big blob when commenting on it. Even if the patch
is megabytes long, and their response is two or three words.
--
A big old stinking pile of genius that no one wants
coz there are too many silver coated monkeys in the world.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120719/0e9359bf/attachment-0002.pgp>
Andre Renaud
2012-07-18 19:43:32 UTC
Permalink
Hi Gaurang,
Post by Gaurang Shastri
Hi All,
Please find attached the initial implementation of "w" command.
{{{
[root at stark toybox-0.3.0]# ./toybox w
root tty2 Wed Jul 11 18:29:24 2012 ( )
rpmuser pts/1 Wed Jul 11 21:33:15 2012 (43.88.80.109)
rpmuser pts/2 Wed Jul 11 19:23:09 2012 (:0.0)
rpmuser pts/3 Tue Jul 17 20:33:41 2012 (43.88.80.208)
}}}
Dear Rob, let me know your comments if any.
Thanks & Regards,
Gaurang Shastri
I would recommend that you combine all of the xprintf's into a single
one, as well as some minor shuffling of your carriage returns:
if (x->ut_type==7)
xprintf("%-9.8s%-9.8s %4.24s (%-1.12s)\n",
x->ut_user, x->ut_line, ctime(&x->ut_tv.tv_sec), x->ut_host)

Regards,
Andre
Rob Landley
2012-07-19 01:29:31 UTC
Permalink
Post by Gaurang Shastri
Hi All,
Please find attached the initial implementation of "w" command.
{{{
[root at stark toybox-0.3.0]# ./toybox w
root tty2 Wed Jul 11 18:29:24 2012 ( )
rpmuser pts/1 Wed Jul 11 21:33:15 2012 (43.88.80.109)
rpmuser pts/2 Wed Jul 11 19:23:09 2012 (:0.0)
rpmuser pts/3 Tue Jul 17 20:33:41 2012 (43.88.80.208)
}}}
Dear Rob, let me know your comments if any.
Applied, and cleaned up a bit.

I note that the w in ubuntu 10.04 gives several more fields, such as
idle time. Does this match the one in android...?

Thanks,

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Gaurang Shastri
2012-07-18 13:40:54 UTC
Permalink
Hi All,

Please find attached the initial implementation of "w" command.

Output after compiling my code with toybox :
{{{
[root at stark toybox-0.3.0]# ./toybox w
USER TTY LOGIN@ FROM
root tty2 Wed Jul 11 18:29:24 2012 ( )
rpmuser pts/1 Wed Jul 11 21:33:15 2012 (43.88.80.109)
rpmuser pts/2 Wed Jul 11 19:23:09 2012 (:0.0)
rpmuser pts/3 Tue Jul 17 20:33:41 2012 (43.88.80.208)
}}}

Dear Rob, let me know your comments if any.

Thanks & Regards,
Gaurang Shastri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120718/35529b25/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: w.c
Type: text/x-csrc
Size: 937 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20120718/35529b25/attachment-0002.c>
Tim Bird
2012-07-18 18:40:59 UTC
Permalink
Post by Gaurang Shastri
Hi All,
Please find attached the initial implementation of "w" command.
{{{
[root at stark toybox-0.3.0]# ./toybox w
root tty2 Wed Jul 11 18:29:24 2012 ( )
rpmuser pts/1 Wed Jul 11 21:33:15 2012 (43.88.80.109)
rpmuser pts/2 Wed Jul 11 19:23:09 2012 (:0.0)
rpmuser pts/3 Tue Jul 17 20:33:41 2012 (43.88.80.208)
}}}
Here is some feedback:

It is better to provide the patch inline, in the message body, rather than
as an attachment. This allows people to easily respond to individual
parts of the patch by commenting directly in a response e-mail. Comments
can be placed in-line with the submitted code. Also, even though this
is a standalone program submission, it is good to submit as a patch
against the full source, suitable for application with 'patch -p1
<filename.patch'
at the root of the source tree. Please provide future contributions
in this format.

This looks like a good basic start. Can you please change the help
text a bit:

Show who is logged on and when and from where they logged in.

Also, do you plan to implement the WHAT column? I find this is useful
to get an idea of what users are doing on the system.

-- Tim
Andre Renaud
2012-07-18 19:43:32 UTC
Permalink
Hi Gaurang,
Post by Gaurang Shastri
Hi All,
Please find attached the initial implementation of "w" command.
{{{
[root at stark toybox-0.3.0]# ./toybox w
root tty2 Wed Jul 11 18:29:24 2012 ( )
rpmuser pts/1 Wed Jul 11 21:33:15 2012 (43.88.80.109)
rpmuser pts/2 Wed Jul 11 19:23:09 2012 (:0.0)
rpmuser pts/3 Tue Jul 17 20:33:41 2012 (43.88.80.208)
}}}
Dear Rob, let me know your comments if any.
Thanks & Regards,
Gaurang Shastri
I would recommend that you combine all of the xprintf's into a single
one, as well as some minor shuffling of your carriage returns:
if (x->ut_type==7)
xprintf("%-9.8s%-9.8s %4.24s (%-1.12s)\n",
x->ut_user, x->ut_line, ctime(&x->ut_tv.tv_sec), x->ut_host)

Regards,
Andre
Rob Landley
2012-07-19 01:29:31 UTC
Permalink
Post by Gaurang Shastri
Hi All,
Please find attached the initial implementation of "w" command.
{{{
[root at stark toybox-0.3.0]# ./toybox w
root tty2 Wed Jul 11 18:29:24 2012 ( )
rpmuser pts/1 Wed Jul 11 21:33:15 2012 (43.88.80.109)
rpmuser pts/2 Wed Jul 11 19:23:09 2012 (:0.0)
rpmuser pts/3 Tue Jul 17 20:33:41 2012 (43.88.80.208)
}}}
Dear Rob, let me know your comments if any.
Applied, and cleaned up a bit.

I note that the w in ubuntu 10.04 gives several more fields, such as
idle time. Does this match the one in android...?

Thanks,

Rob
--
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation. Pick one.
Continue reading on narkive:
Loading...