Discussion:
A question of philosophy
(too old to reply)
David Collier
1970-01-01 00:00:00 UTC
Permalink
Denys,

your suggestion above for fixing tar to work with stdin is wonderful -
and I'm sure it will work.

But it illustrates the different world-views that you and I have. In an
illuminating way.

You think/speak as if busybox is infinitely mutable, and an issue can be
changed by improving it. I think of the busybox version I find on
existing computers as part of the fixed background, and am looking at
ways to work with any/all of them without changing them.

If I need to do something to my application, I would like it to work on

the systems I have in the field running feature-lite busybox 0.60
( Good Lord )
the ATNGW-clones which run 1.13 non-desktop
the dev sys on my desk running 1.17 desktop
the PCEngines board which has Debian,
but for some reason also has busybox 1.10 lying around.

I have now understood that
O different revisions of busybox have made different choices
- the standard columns output by ps have changed over time.
O even the same issue level of busybox may have been built with
or without many options - so the ps command may, or may not,
support the -o option to customise it's output.
Therefore I can't depend on the field order, nor on the presence of an
option to alter it
I've solved that by poking around in /proc ... but heaven help us, that
may not even exist on some computers, so I will need yet another level of
complexity for full portability :-(

Without risking breaking those boxes, which are sitting in fields in Peru
and other places, and I CANNOT afford to go and reboot them.

Now you might WELL say to me that I'm looking at it wrong. You may say
that when I install my updated s/w I should also install a new busybox
exe, on whatever machine, and use it.

You might even say that all of my s/w should use "busybox ps", or set a
path at start-up so that busybox is preferred to any Debian utilities
lying around.

Maybe that is the right approach, and I should get used to the idea that
busybox is actually part of my app, not part of the system. Except there
are things in /etc/init.d that use busybox too. Maybe I need to download
and update EVERY script on the system with my app. Better find them all
first.
And if anything else I don't update is doing system() calls I'd better
pray the new busybox works the same.

Perhaps I should set up myapp/sbin myapp/bin myapp/usr/bin and
myapp/usr/sbin and stick those on the front of the path, and set links so
my app sees my latest busybox, but any existing s/w on the machine sees
the environment it was used to...

Do you, or does anyone else here, know how to square this circle?

D






In article <201102030402.43422.vda.linux at googlemail.com>,
*From:* Denys Vlasenko <vda.linux at googlemail.com>
*To:* busybox at busybox.net
*Date:* Thu, 3 Feb 2011 04:02:43 +0100
# find . -depth -print | pax -wd > outfile.tar
That would be more portable (not all systems have /proc)
Not all systems have a nice place you can safely write
a list file, either. One would also need to arrange to clean
up this file afterwards, and to make sure it was not included
in the list itself, or else is given to tar as an exclusion.
Ideally the list file is auto-generated, and's a name that can
never collide. mktemp stuff.
Either way, potential complications. I'm still trying
to get used to /proc/self/fd/0 versus /dev/stdin!
find . -depth -print | tar ... -T -
--
vda
diff -ad -urpN busybox.5/archival/tar.c busybox.6/archival/tar.c
--- busybox.5/archival/tar.c 2011-01-31 05:50:34.000000000 +0100
+++ busybox.6/archival/tar.c 2011-02-03 03:59:05.000000000 +0100
@@ -655,7 +655,7 @@ static llist_t *append_file_list_to_list
llist_t *newlist = NULL;
while (list) {
- src_stream = xfopen_for_read(llist_pop(&list));
+ src_stream = xfopen_stdin(llist_pop(&list));
while ((line = xmalloc_fgetline(src_stream)) != NULL) {
/* kill trailing '/' unless the string is just "/" */
char *cp = last_char_is(line, '/');
_______________________________________________
busybox mailing list
busybox at busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Lauri Kasanen
2011-02-03 11:49:35 UTC
Permalink
Post by David Collier
Maybe that is the right approach, and I should get used to the idea that
busybox is actually part of my app, not part of the system. Except there
are things in /etc/init.d that use busybox too. Maybe I need to download
and update EVERY script on the system with my app. Better find them all
first.
And if anything else I don't update is doing system() calls I'd better
pray the new busybox works the same.
Thinking that bb is a part of your app is fine. A fairly easy solution to not conflicting with the system's busybox is to name yours busybox2, or whatever. Then call "busybox2 ps", and you know exactly what output you get.

- Lauri
--
_______________________________________________
Surf the Web in a faster, safer and easier way:
Download Opera 9 at http://www.opera.com
David Collier
1970-01-01 00:00:00 UTC
Permalink
Post by Lauri Kasanen
yours busybox2, or whatever. Then call "busybox2 ps", and you know
exactly what output you get.
I'm beginning to think that is the only usable solution.

But hacking all my scripts to add busybox<space> will make them
unreadable and take ages. And sometime I'd forget, or the next programmer
would.

I could try now and forever to identify when it matters and when it
doesn't, but that's too much overhead.

I think installing the new busybox version with my app, and hacking the
path as seen by my app is the only acceptable route.

I actually have a script set-standard-path.sh, which I have to invoke in
the OpenVPN call-back scripts, as they start with no path set. So I'd
just have to do that anywhere and everywhere at the start of all scripts.

I use a common preamble included into all my scripts, so I can add it
there.

My isn't this fun :-)

D
Post by Lauri Kasanen
- Lauri
--
_______________________________________________
Download Opera 9 at http://www.opera.com
Denys Vlasenko
2011-02-04 22:27:31 UTC
Permalink
Post by David Collier
Post by Lauri Kasanen
yours busybox2, or whatever. Then call "busybox2 ps", and you know
exactly what output you get.
I'm beginning to think that is the only usable solution.
If you will be forced to do this, name them busybox-N.M
with version suffix.
--
vda
Tito
2011-02-03 20:28:48 UTC
Permalink
Post by David Collier
I've solved that by poking around in /proc ... but heaven help us, that
may not even exist on some computers, so I will need yet another level of
complexity for full portability
Hi,
Doesn't ps scan /proc?
If it is not mounted nor busybox ps nor a script nor real ps would work.
I would scan /proc myself to be sure the ouput is formatted the way I like it.

Just my 2 cents.
Ciao,
Tito
Rich Felker
2011-02-04 01:40:30 UTC
Permalink
Post by David Collier
Denys,
your suggestion above for fixing tar to work with stdin is wonderful -
and I'm sure it will work.
But it illustrates the different world-views that you and I have. In an
illuminating way.
You think/speak as if busybox is infinitely mutable, and an issue can be
changed by improving it. I think of the busybox version I find on
existing computers as part of the fixed background, and am looking at
ways to work with any/all of them without changing them.
I think it depends a lot on whether you're:

1) writing scripts to run on systems you know will be using BusyBox,
possibly an old version of it, OR

2) setting up a system that should be able to run arbitrary scripts
that work on an existing environment or standard (Linux+GNU userspace
or POSIX for instance), and wanting to use BusyBox in place of the
traditional bloated implementations.

In the first case, BusyBox (possibly with bugs) is the static
background you're stuck with. In the latter case, some known "good
profile" is the static background you're fortunate enough to be
assuming, and you want BusyBox to conform to that.

I for one am definitely in the latter camp.

Rich
David Collier
1970-01-01 00:00:00 UTC
Permalink
In article <201102032128.48236.farmatito at tiscali.it>,
Post by Tito
Hi,
Doesn't ps scan /proc?
If it is not mounted nor busybox ps nor a script nor real ps would
work.
I would scan /proc myself to be sure the ouput is formatted the way
I like it.
Just my 2 cents.
Ciao,
Tito
Tito,

I dunno :-)

I have just heard that on some Linux machines there's an issue with
reading /proc - either it doesn't exist or isn't accessible to apps.

I've just written ps.sh which pokes around in proc and dumps pid, stat
and cmd line. It will work on any of the machines I'm currently looking
at.

On the main subject, I'm coming to the conclusion that if I want to have
100 scripts plus some C programs which do system() a lot.... I need to
include a 'known' version of busybox for them all to use in my
distribution, not to rely on whatever is lying about on the Linux
computer I try to install on.

D
David Collier
1970-01-01 00:00:00 UTC
Permalink
Rich,

I have to ship on day 1 on a range of boxes which are currently running
busybox 0.60, 1.10, 1.13 and 1.17

I'm reluctant to blat the existing busybox as part of my upgrade/install
process. Who knows what else I might break.

I also have the first unit here where I'm trying to install on a
PCEngines embedded PC, which comes with both a set of standard Linux
utils, and an odd copy of busybox lying about for no purpose I've yet
understood !

My desire is to ship a suite of scripts and program which will install
and run on any of these without a hitch. That may well mean I can't use
the 'much better' non-busybox utilities and commands, even when available.


D
*From:* Rich Felker <dalias at aerifal.cx>
*To:* busybox at busybox.net
*Date:* Thu, 3 Feb 2011 20:40:30 -0500
Post by David Collier
Denys,
your suggestion above for fixing tar to work with stdin is
wonderful -
and I'm sure it will work.
But it illustrates the different world-views that you and I have.
In an
illuminating way.
You think/speak as if busybox is infinitely mutable, and an issue
can be
changed by improving it. I think of the busybox version I find on
existing computers as part of the fixed background, and am
looking at
ways to work with any/all of them without changing them.
1) writing scripts to run on systems you know will be using BusyBox,
possibly an old version of it, OR
2) setting up a system that should be able to run arbitrary scripts
that work on an existing environment or standard (Linux+GNU
userspace
or POSIX for instance), and wanting to use BusyBox in place of the
traditional bloated implementations.
In the first case, BusyBox (possibly with bugs) is the static
background you're stuck with. In the latter case, some known "good
profile" is the static background you're fortunate enough to be
assuming, and you want BusyBox to conform to that.
I for one am definitely in the latter camp.
Rich
_______________________________________________
busybox mailing list
busybox at busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Denys Vlasenko
2011-02-04 22:24:25 UTC
Permalink
Post by David Collier
Denys,
your suggestion above for fixing tar to work with stdin is wonderful -
and I'm sure it will work.
But it illustrates the different world-views that you and I have. In an
illuminating way.
You think/speak as if busybox is infinitely mutable, and an issue can be
changed by improving it.
Of course, that's what developers do: they change software.

However, I do not change busybox in a random way. I generally try to make
busybox tools more similar to tools available on "big Linux",
so that people can use the same scripts and expect the same
behavior.

In this particular example, "tar -T -" is supported by GNU tar,
therefore I made busbox tar to do the same.
Post by David Collier
I think of the busybox version I find on
existing computers as part of the fixed background, and am looking at
ways to work with any/all of them without changing them.
If I need to do something to my application, I would like it to work on
the systems I have in the field running feature-lite busybox 0.60
( Good Lord )
the ATNGW-clones which run 1.13 non-desktop
the dev sys on my desk running 1.17 desktop
the PCEngines board which has Debian,
but for some reason also has busybox 1.10 lying around.
I have now understood that
O different revisions of busybox have made different choices
- the standard columns output by ps have changed over time.
O even the same issue level of busybox may have been built with
or without many options - so the ps command may, or may not,
support the -o option to customise it's output.
Therefore I can't depend on the field order, nor on the presence of an
option to alter it
I've solved that by poking around in /proc ... but heaven help us, that
may not even exist on some computers, so I will need yet another level of
complexity for full portability :-(
Well, world is full of computer systems, and their upgrade cycles
can be wildly different (and sometimes really haphazard).
Post by David Collier
Without risking breaking those boxes, which are sitting in fields in Peru
and other places, and I CANNOT afford to go and reboot them.
Now you might WELL say to me that I'm looking at it wrong. You may say
that when I install my updated s/w I should also install a new busybox
exe, on whatever machine, and use it.
No, I understand you might have no control over that.
Post by David Collier
You might even say that all of my s/w should use "busybox ps", or set a
path at start-up so that busybox is preferred to any Debian utilities
lying around.
Maybe that is the right approach, and I should get used to the idea that
busybox is actually part of my app, not part of the system. Except there
are things in /etc/init.d that use busybox too. Maybe I need to download
and update EVERY script on the system with my app. Better find them all
first.
And if anything else I don't update is doing system() calls I'd better
pray the new busybox works the same.
Perhaps I should set up myapp/sbin myapp/bin myapp/usr/bin and
myapp/usr/sbin and stick those on the front of the path, and set links so
my app sees my latest busybox, but any existing s/w on the machine sees
the environment it was used to...
Do you, or does anyone else here, know how to square this circle?
You will need to test your scripts on every deployed config
and try to write scripts so that they work on all configs
you support. If this is impossible, sometimes you will need
to have several version of a script.

To reduce amount of PITA, try to minimize the number
of deployed configurations.
--
vda
David Collier
1970-01-01 00:00:00 UTC
Permalink
Denys,

I have no word of complaint about you changing busybox... I think it's a
great project, and I approve of the direction it's moving in.

I'm just highlighting the fact that no improvement you do to the current
build can fix what I encounter on existing computers.

On top of that I find that for simplicity I need a constant shell
environment

I really don't want to face trying to write scripts without functions..
and as far as I can see the ash syntax is incompatible with the bash one,
and vice-versa.

So at this moment I'm tempted to bundle busybox with my application, and
get it to use only the bundled busybox. That gives me back the control I
need.

D


In article <201102042324.25855.vda.linux at googlemail.com>,
*From:* Denys Vlasenko <vda.linux at googlemail.com>
*To:* busybox at busybox.net, from_busybox_maillist at dexdyne.com
*CC:* Andrew at dexdyne.com, jeredb at dexdyne.com
*Date:* Fri, 4 Feb 2011 23:24:25 +0100
Post by David Collier
Denys,
your suggestion above for fixing tar to work with stdin is
wonderful -
and I'm sure it will work.
But it illustrates the different world-views that you and I have.
In an
illuminating way.
You think/speak as if busybox is infinitely mutable, and an issue
can be
changed by improving it.
Of course, that's what developers do: they change software.
However, I do not change busybox in a random way. I generally try
to make
busybox tools more similar to tools available on "big Linux",
so that people can use the same scripts and expect the same
behavior.
In this particular example, "tar -T -" is supported by GNU tar,
therefore I made busbox tar to do the same.
Post by David Collier
I think of the busybox version I find on
existing computers as part of the fixed background, and am
looking at
ways to work with any/all of them without changing them.
If I need to do something to my application, I would like it to
work on
the systems I have in the field running feature-lite busybox
0.60 ( Good Lord )
the ATNGW-clones which run 1.13 non-desktop
the dev sys on my desk running 1.17 desktop
the PCEngines board which has Debian,
but for some reason also has busybox 1.10 lying around.
I have now understood that
O different revisions of busybox have made different choices
- the standard columns output by ps have changed over time.
O even the same issue level of busybox may have been built with
or without many options - so the ps command may, or may not,
support the -o option to customise it's output.
Therefore I can't depend on the field order, nor on the presence
of an
option to alter it
I've solved that by poking around in /proc ... but heaven help
us, that
may not even exist on some computers, so I will need yet another
level of
complexity for full portability :-(
Well, world is full of computer systems, and their upgrade cycles
can be wildly different (and sometimes really haphazard).
Post by David Collier
Without risking breaking those boxes, which are sitting in fields
in Peru
and other places, and I CANNOT afford to go and reboot them.
Now you might WELL say to me that I'm looking at it wrong. You
may say
that when I install my updated s/w I should also install a new
busybox
exe, on whatever machine, and use it.
No, I understand you might have no control over that.
Post by David Collier
You might even say that all of my s/w should use "busybox ps", or
set a
path at start-up so that busybox is preferred to any Debian
utilities
lying around.
Maybe that is the right approach, and I should get used to the
idea that
busybox is actually part of my app, not part of the system.
Except there
are things in /etc/init.d that use busybox too. Maybe I need to
download
and update EVERY script on the system with my app. Better find
them all
first.
And if anything else I don't update is doing system() calls I'd
better
pray the new busybox works the same.
Perhaps I should set up myapp/sbin myapp/bin myapp/usr/bin and
myapp/usr/sbin and stick those on the front of the path, and set
links so
my app sees my latest busybox, but any existing s/w on the
machine sees
the environment it was used to...
Do you, or does anyone else here, know how to square this circle?
You will need to test your scripts on every deployed config
and try to write scripts so that they work on all configs
you support. If this is impossible, sometimes you will need
to have several version of a script.
To reduce amount of PITA, try to minimize the number
of deployed configurations.
--
vda
Paul Smith
2011-02-07 15:52:38 UTC
Permalink
Post by David Collier
I really don't want to face trying to write scripts without
functions.. and as far as I can see the ash syntax is incompatible
with the bash one, and vice-versa.
That's not true. ash supports shell functions as defined by POSIX, and
so does bash.

If you write POSIX standard shell scripts and use #!/bin/sh at the top,
they will work correctly both on systems where /bin/sh is bash and
where /bin/sh is ash [1].

Of course if you write scripts that use bash-specific syntax, rather
than POSIX standard syntax, then you need to prefix your script with
#!/bin/bash instead of #!/bin/sh, and obviously those scripts will not
work on systems where /bin/bash is not installed/does not exist.


We will just tiptoe quietly past the mess of goo on the sidewalk that is
Solaris /bin/sh, and pretend we didn't notice it there.


[1] Modulo bugs of course.
Harald Becker
2011-02-07 22:18:33 UTC
Permalink
Hallo David!
Post by David Collier
I really don't want to face trying to write scripts without functions..
and as far as I can see the ash syntax is incompatible with the bash one,
and vice-versa.
Incompatible? ... in which way?

myfunction () {
... add your statements here
}

... that should work with ash and bash and other compatible shells too.
You just need to have an eye on your function names. As far as I know
the standard says such names allow only letters, digits and underline.
bash allows some other characters to be included in function names, so
you need to avoid those.

... so why do you think functions are incompatible between bash and ash?

--
Harald
David Collier
1970-01-01 00:00:00 UTC
Permalink
Paul

thanks,

I have the wrong end of a stick somewhere.

I had some sort of issue with function syntax when I was first getting
experience... I can't now recall the details.

If I ever work out what it was, beyond ignorance and finger-trouble....

D

Continue reading on narkive:
Loading...