>I would expect it to be "/root" considering that USER has been set to "root"...
Who says there has to _be_ a "/root" directory?
-- Jim
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
>I fought through the bash startup scripts almost 20 years ago in
>college, and still have "source .bashrc" in my ~/.bash_profile that >I've
>been carrying from system to system ever since :-)
>and my PATH has never had '.' in it. Your explanation makes
>perfect sense though.
My understanding
My understanding, from years past, is that "source " (or ". ") is
_exactly_ the same as "", except that it's running in _this_ shell rather
than in a subshell. Thus it is able to affect environment variables that
subsequent commands can inherit, etc.
If "." is not in your PATH, and you want
The rule is pretty simple: If you die, and your parent is still in the process
list (regardless of its state), then you're a zombie until your parent reaps
you. If you die and your parent is not in the process list, then init(8) reaps
you at its earliest convenience. If you're a zombie and
>Unconditionally sleeping when signals may arrive is a no-no.
It used to be that sleep(3) was interruptible. Is this no longer the case?
Who broke libc, and when?
-- Jim
___
busybox mailing list
busybox@busybox.net
I concur. If a process's parent dies, that process will NOT be a zombie, no
way no how, unless either the system's init(8) process is broken, or there is
some kind of bug in the kernel. You do not need to reap your own children
before dying, and you never have, not on any flavor of Unix since
>Is there a reason why BusyBox's [reboot] implementation is different, or is it
>a bug?
None of the above? A sync(2) call, wherever found, is not the be-all and
end-all of filesystem cleanup. It just gets the fs cache-cleaning party
started. More than one is just fine, even zero is fine.
Anybody here ever actually used dd to read from an actual _tape_ drive? Short
reads are the norm, there. (Or were.) The bs= size was the _maximum_ record
size, but the records could be, and often were, shorter. Please don't break dd
so that it can only work on 'b'lock devices, and not
>If you've got a command prompt, then getty isn't running -- the shell is.
Yes.
>If you've got a _login_ prompt, then getty is running.
Close! Getty _might_ be running, or perhaps /bin/login
is. Could be either, depending on how you got there.
-- Jim
"VAR=value make..." is 100% identical to
"export VAR=value; make...", from the point
of view of make and its children. Perhaps
try that?
-- Jim
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
>I want to make this the shortest command possible is because I don't want to
>add 60 lines of code to a script just to copy
>10 files (with error control and so forth).
This sounds like an excellent opportunity to make a function,
or to feed an embedded pipe with a list...
while read f; do
So you've written a shell script that relies upon non-POSIX
behavior, specifically GNU bash extensions, and it doesn't
work in POSIX-ey ash. No big surprise. You will have to
do it differently, or install bash on your target. Same
dilemma everybody else faces when dealing with 'small' targets.
>I have a personal grudge against blocking system calls.
As do I, they're evil, evil, evil if you're trying to
write anything more involved/interactive than a pipeline
component.
-- Jim
___
busybox mailing list
busybox@busybox.net
>of course, when you say 1992, that is still "new" compared to
>UNIX systems that existed at the time.
Indeed. Unix/init had been running for about 20 years by that time.
-mike
___
busybox mailing list
busybox@busybox.net
Some history, as I recall it:
Unix hard-coded "init" as PID 1, and (I believe) hard-coded the
initial search path to "/bin" and "/usr/bin".
Unix didn't pass any command-line arguments _to_ init, because
there was no environment from which they could come. Most especially,
the concept of
So what's wrong with:
.,$d
-- Jim
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
> Is anyone is this list anymore?
No. :-)
-- Jim
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
I am not set up to do so, but I have examined the sources
in 1.24 (current?) and the -xdev handling code is unchanged
from what I am testing.
-- Jim
-Original Message-
From: Bastian Bittorf [mailto:bitt...@bluebottle.com]
Sent: Tuesday, December 01, 2015 11:45 AM
To: Cathey, Jim
Cc
Unless you need the enhance dynamic range abilities of
floating point, you shouldn't be using it at all. That's
just a general principle. Devcie temperatures are well
handled by fixed-point (integer) routines.
-- Jim
-Original Message-
From: busybox [mailto:busybox-boun...@busybox.net]
For this case I generally cast the param to the biggest possible type.
printf(llu, (uint64_t) val);
That's nearly as parochial as what you are changing from. C doesn't
have a printf-name to _size_ mapping. What if my C compiler has a
128-bit scalar type, and _that_ is long-long? The best thing
Stream-writes [pipe] are not atomic, and your message can theoretically get
cut in half and interleaved with another process writing the same fifo.
Any pipe, whether named or not, IS atomic so long as the datagrams
in question are smaller than PIPE_BUF in size. This has been true
since Day 1, in
At the bottom, some of C's arithmetical rules
are 'stupid'. Especially as regards type
promotion. At least they're well-defined.
Absolutely true in a mathematical sense is that
the difference between two unsigned numbers is
SIGNED! But that's not what C does. You can get
around this, easy
Because we don't expect machines to run for 68 years without reboot.
Certain nameless-but-large customers out in the world, running certain
nameless Linux/busybox-based products, have experienced abject system
failures after longer runtimes. Two years is one such number. These
are generally
While 68 years does seem a stretch, who in their right
mind wants to code implicit time-bombs into their stuff?
A vendor wants to be able to say I'm game if you are.
(I.e., totally NOT a microsoft mentality! Which is to
say, reboot every few days else it stops working right.)
Handling monobased
I doubt having the boot process continue with the wrong time would be
acceptable. File timestamps will be wrong until the background process
completes. You really want to wait synchronously for an answer.
That, of course, is not the tool-maker's call. The _system_
designer gets to decide how
Because mathematically, differences are always signed!
2 - 1 == 1
1 - 2 == -1
Doesn't matter what the size, or sign-ability of the LHS
operands are. C, however, absolutely stinks at mathematical
relations that change the nature of the calculation. Precision
Oh, and carry bits. Addition/subtraction are also precision-changing!
-- Jim
From: busybox [mailto:busybox-boun...@busybox.net] On Behalf Of Cathey, Jim
Sent: Tuesday, January 27, 2015 2:19 PM
To: Guillermo Rodriguez Garcia; Tim Hentenaar
Cc: busybox; Rich Felker
Subject: RE: [PATCH] udhcpd
Things like 'top' have _always_ had issues with processes
that are clock-synchronized. Very few OS's (and I don't
think Linux is one of them) actually account CPU time
by use of things like the PPC TBR register (for example).
Most do it via statistical sampling in a clock interrupt.
The
If you can't modify the kernel to collect more accurate
data (like we did with our top-oid in OSE), you have to
get a lot smarter. Set up some 'offline' processing of
bulk data, NON-clock synchronized, and characterize that.
(i.e. I can process 1000 records/second in a non-clock-synced
loop,
Pretty sure 'our' upstream rm (in a prior life) expressly
prohibited -r on starting paths that contained .. members.
Too many weirdo cases where you would get into trouble.
-- Jim
-Original Message-
From: busybox [mailto:busybox-boun...@busybox.net] On Behalf Of Ralf Friedl
Sent:
I would HOPE that flash memory has improved in the past 20 years,
The underlying physics really hasn't. Some devices are more
robust, but the less expensive ones aren't. They're a lot bigger,
is all. You need to KNOW where and what is kept, if you want to
have any confidence in the long-term
I don't like warnings on perfectly legal C.
Promoting them to errors is even worse.
That said, even with all this crap, provided
that the strings are constant and don't contain
substitutions the compiler has nothing to
complain about.
-- Jim
From: busybox-boun...@busybox.net
Embedded != consumer electronics.
Indeed. Our products use Busybox,
and with some of them it's not
impossible to push the per-unit price
into seven figures (USD). They
are flash-based, not disk-based,
and file space is at a modest premium,
which is why BB is being used to
begin with.
Only
Am I missing something here? There is no structure, just a character
pointer. If you leave off static it will be compiled as an
instruction that pushes a constant onto the stack, by any/every compiler.
Which is probably _larger_ code than just referring to something
stored in the .text/.data
The entire point of unlink, the reason it even
exists, is that it never takes _any_ options.
Anything you feed it is a filename, and it
will delete it.
-- Jim
___
busybox mailing list
busybox@busybox.net
Coreutils was not first. IMHO, if it takes options
of any sort it is broken. You only use unlink when
you _don't_ want options.
-- Jim
-Original Message-
From: Denys Vlasenko [mailto:vda.li...@googlemail.com]
Sent: Monday, June 23, 2014 10:44 AM
To: Cathey, Jim
Cc: busybox@busybox.net
Another issue that is often not thought about by
many embedded developers, is that flash devices
slow down with wear. Excessive logging to flash
eventually results in a device that might no longer
meet its performance objectives. The flashes I'm
most familiar with have something like a 20:1
Generally C compilers assume that an address
passed to a function (free(p)) _might_ be dereferenced,
and so would not optimize away the memset(p,...)
If a particular C compiler thinks it knows what
free() is, and that it doesn't dereference its argument,
then it might think it was justified in
char pwd[64];
memset(pwd, 0, sizeof(pwd));
if (pwd[0] != '\0') {
printf(memory not zeroed);
or would the compiler see that we read just first char
and zero only that and force us to check every
char of pwd?
If CC knows what memset does (and I believe they
generally do these days),
What do you call observable?
C has a pretty exact definition of this.
Replacing the content of a memory region by a constant value is
an observable effect by itself.
No, it's not. Where did you _get_ the address to observe?
That's the essence of the observability question.
The C compiler
I'll fix the bug, but why your writes are so slow?
Flash _is_ slow.
Kernel is supposed to buffer writes to filesystems.
That only works, to a point. Perhaps write-through
is engages on this _system_, for fitness of purpose
reasons? The point is, you can't _count_ on buffering
to hide bugs!
This long predates Linux. Some small
percentage of programs rely upon being
able to modify the argv array. This
is especially valuable to programs
that fork heavily but that do not exec.
The individual tines may thus be labeled
with their roles so that they can be
identified in ps, for example.
The only thing BB would need would be to isolate initialization
into separate functions that would be grouped together by the
linker. (And an associated link control file.) The usual demand-paged
kernel will take care of the rest. Page granularity is large enough that,
without grouping like
Gcc has an attribute you can assign, I'm using it
to push some .idata into .text that I want read-only.
#ifndef TEXTSEG
# ifdef __GNUC__
#define TEXTSEG __attribute__((section (.text#)))
# else
#define TEXTSEG
# endif
#endif
...
const Type instance[] TEXTSEG = {...};
...
You could use
I think that a project's charter should define
what it does _not_ do just as much as what it _does_.
That can help avoid feeping creaturism that ends
up rendering it unsuitable for its main use(s).
-- Jim
___
busybox mailing list
busybox@busybox.net
A separate suid-exec relay utility is in fact exactly what
we use on our BB installation in our product, and have
for years. BB itself is not suid, I/we didn't trust it
enough. Here it is:
/*
** Relay execution program to setuid-root selected busybox functions.
** (We are expected to be
This is on a read-only root filesystem that is built the way we want it.
(Squashfs, I believe.) There aren't any, and can't be, any links to names
we don't wish to give suid permission to.
-- Jim
-Original Message-
Where's the check for what applets are allowed? What stops you from
] On Behalf Of Peter Korsgaard
Sent: Thursday, January 09, 2014 12:46 PM
To: Cathey, Jim
Cc: Laurent Bercot; Denys Vlasenko; busybox
Subject: Re: [PATCH] ping: try SOCK_DGRAM if no root privileges
Cathey, == Cathey, Jim jcat...@ciena.com writes:
This is on a read-only root filesystem that is built
...@busybox.net [mailto:busybox-boun...@busybox.net] On
Behalf Of Cathey, Jim
Sent: Thursday, January 09, 2014 1:24 PM
To: Peter Korsgaard
Cc: busybox
Subject: RE: [PATCH] ping: try SOCK_DGRAM if no root privileges
Doesn't really do you much good since BB is still doing
its own name checks.
No, it's
So if I should type, manually, . oopsImisspelledIt
my session is supposed to go away?
Not cool.
-- Jim
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
source comes from the C shell.
The Bourne shell (and the Korn shell
successor) did not have it.
Bash was probably the first to suck in
both.
-- Jim
-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net] On
Behalf Of Harald Becker
Sent: Friday, March
I'd really be interested in knowing how you
could mess up close() that bad...
At a guess:
int
close(int fd)
{
if (array[fd].isOpen) {
...
}
}
Rich
___
busybox mailing list
busybox@busybox.net
Of course this also has down-sides, such as losing extended attributes
and other file properties the application is not aware of, and not
being able to preserve ownership.
It also breaks hard links. Keeping FD's open is not
normal for most Unix tools of this sort.
-- Jim
I would hope large corporate or university networks have proper
backup power so that power failures don't occur.
That is absolutely nothing that a protocol should be
designed to rely upon! Network restart scenarios should
_always_ be reliable, no matter what the provocation.
-- Jim
This is a uLibc fault. A common idiom,
from way back, is:
close(creat(...));
Close is supposed to be able to survive being
given a negative number.
-- Jim
-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net]
On Behalf Of Waldemar Brodkorb
Another solution would be to use sed 's/$/^M/' | telnet ...
you don't want sed to buffer the data...not implemented in busybox sed
The canonical cr-lf translation is to use tr, not sed.
-- Jim
___
busybox mailing list
busybox@busybox.net
mkdir(sub, 0700);
chroot(sub);
chdir(../../../../../../../../..);
chroot(.);
If that works, the kernel is broken IMHO.
Or is this predicated on the CWD not being
somewhere in the chroot path to begin with?
-- Jim
___
busybox mailing list
Is not one of the ways to manage delta-time
timeouts to use uptime() instead of time()?
You don't care what time it is, you only want
to manage a timeout on the order of seconds,
so a monotonic time source like uptime() is
actually preferable.
It seems to me that 64-bit math is unnecessarily
My (lay) understanding of this is that there are two separate
issues:
1) Company contributes (back) to the project.
2) Company provides sources of whatever they did.
Obviously #1 is preferable, assuming the mods are palatable,
but only #2 is required. It would take an interested (and
possibly
Aren't most uses of 0666 implicitly assuming
some umask activity? I know that the common
umask of 022 will turn this into 0644, which
is usually what you want.
However, we have a system where U=G almost always
in order to have the desired functionality,
and there the default umask is 02,
I'd like to know how else, other than this ugly SIGCHLD handler, you
can create a child process without having the keep track of the pid
and have part of your code be responsible for waiting for it.
Just use the asynchronous waitpid. Oh, sorry, we're not talking
about DNIX here are we? :-) Its
Well yes, if poll() keeps lying about event availability, then your
program will loop a few times without doing any progress. But that is
not a problem in poll's design, it's a problem in the implementation.
Lying about event availability is not supposed to happen often.
According to Rich, it is
That's why I propose we don't multiply syscalls, but extend existing
socket I/O ops to work on non-sockets.
IMHO it cannot be more elegant.
Only in one way can it become more elegant. Eliminate sockets
altogether, making them the fd's that they always should have been. :-)
-- Jim
there are some fundamentally unsolvable issues
(like who owns a process-shared mutex after fork?
I should have been more clear. Our problem was that the forking
multithreaded _parent_ died with a SEGV! The children, single-threaded
and going on to an immediate exec, were just fine.
that, it
It doesn't; it can't. Hence my ranting. A 100% safe
100% orthogonal, useful easy-to-use AIO mechanism should
have been designed
Would the hypothetical nonblock_read() and nonblock_write() system
calls suggested at http://cr.yp.to/unix/nonblock.html be a good
enough design, or do you think
I understand what you mean, but poll() loops, despite the misleading
name of the central primitive, are not doing any polling at all. poll()
works by notification, not by polling (... at least I hope that kernel
developers have the good sense to make it so).
The underlying OS details are,
No. The paradigm in wait until some event happens, then react on it.
The most important feature of select/poll is that they
*wait for something to happen*, and can wait for a set of events,
not just one event.
That is true, so far as it goes, but it's the nature of 'something'
that is one of the
Doing asynchronous loops without O_NONBLOCK does not feel right.
Agreed. Doing asynchronous loops with a true AIO structuring
feels _very_ right. (Keep your program state in a control
block, not in the program counter.) The problems just go away.
-- Jim
This discussion is an illustration of why nonblocking I/O
is itself inherently evil, and shouldn't even really exist.
(It is just busy-wait polling, in disguise.)
If complex programs are instead coded in an event-driven manner,
using AIO techniques, they can work with blocking (flow-control
I ask you how to perform nonblocking reads safely.
You can't, not 100%.
Because from where I sit, current Unix API doesn't provide
for 100% safe (wrt races) way to do it.
It doesn't; it can't. Hence my ranting. A 100% safe
100% orthogonal, useful easy-to-use AIO mechanism should
have been
These 3 examples do the same thing...
And a fourth, which tends to be the way I do
such things:
(P=/usr/local/people/ mkdir -p $P cd $P mkdir me you others)
-- Jim
___
busybox mailing list
busybox@busybox.net
Looks like whatever it was that tried to invoke
the kill command didn't use a shell to parse it
first.
-- Jim
-Original Message-
From: busybox-boun...@busybox.net [mailto:busybox-boun...@busybox.net]
On Behalf Of Gilles
Sent: Wednesday, July 06, 2011 4:19 PM
To: busybox@busybox.net
Once upon a time login shell activity was triggered
by the first character of argv[0] (to the shell) being
a '-' character. Strange, and maybe stupid, but that's
how it was done. The -l option was just to trigger
(manually) the automatic '-/bin/sh' behavior, when you
needed it in scripts.
Our
There are exactly two characters (of an unsigned char)
that cannot be in a Unix filename: '/', which is the
path component separator, and '\0'. Everything else,
including newlines and spaces, is perfectly legal
in a filename, though perhaps incredibly annoying
to deal with if present. The \0
Actually, xargs (the standard one, without -0) accepts a shell-quoted
list of filenames, so rather than -print0, find could have just been
Maybe now they do, but when they were first written
they did not. (Or so I understand.) The -print0 solution
was the easy/obvious choice, especially given
There's no point in C programs reading the output of find -print0.
Agreed. It was for find|xargs pretty much alone, and there it
works wonderfully well. Shell quoting, in the early days, was
perhaps not so 100% foolproof as a utility to clean up directories
might need. The NUL-delimiter
When you unlink a binary that is being executed (for instance:
/bin/busybox), said binary is not deleted at once, because it is still
in use (processes executing it have a fd open on it). The binary is
just marked for deletion; when all processes executing it have exited,
the real deletion occurs.
This is somewhat difficult or impossible to do in a conformant way.
Each open file has a device and inode number which cannot change for
its lifetime, which are important identifiers that may be used in
security-critical ways.
In this (DNIX) system the file was not 'open' at the user level,
and
A better approach in my mind would be to move the orphaned inodes to
an invisible directory whose contents are automatically deleted at the
next mount (by the mount utility or the kernel). The kernel could also
wipe them when the last reference is closed, but only if the device is
mounted for
Please forgive the un-real patch-oid format, but we're not
set up to do it better right now. We've got a script that
pipes GNU ls -C into BB more, and it really messes up the
tabs. I made a quick patch to more.c which seems to help.
Any reason this shouldn't be permanent? The crude conversion
then any kind of kill, including SIGKILL, on fred should send svlogd an
EOF and it should shut down pronto.
Specifically: any kind of _death_, whether caused by a signal
or not, will give svlogd an EOF. (Plenty of signals don't
necessarily cause death, for example.) Unless somebody else
has
In Denys' fix, he closes STDIN when the inactivity timer pops. I
wonder why that messes up the terminal?
Perhaps because shells routinely mess up the terminal
in normal operation, and this interfered with its trying
to put it back? (Also routine.)
-- Jim
... hey Denys, could you try to close only stdin on alarm and do the
terminal restore on stdout/stderr instead? ... just as a hint for a
possible solution.
Shells have historically always used STDIN for the
tty settings, due to the extremely common cases where
stdout/stderr are redirected.
Y'all
Whereas find /tmp -mindepth 1 -maxdepth 1 ! -type d -print0 \
| xargs -r0 rm -f will succeed. More
complicated, to be sure, but more robust.
Jim - I'm quite interested in this issue - a customer has just forced
us
to up the spec on our data logger so it may have to delete 1000+
busybox refuses to play nicely with
tar -cf test -T /dev/null
or
tar -cf test /dev/null
so is there any other way to get there?
As with all unixen there's always another way!
Once upon a time tar files were simple enough
that you could concatenate them. Perhaps that
is no longer true? You
# 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
I notice that getty has a timeout - does this take care of inactivity
in the shell?
No.
And I also noticed that ash has no timeouts in the source at all.
Completely normal.
I can code an idle timeout into ash, but I wanted to check...
Please don't.
Idle timeouts are always implemented
The idle timeout program (and I forget the name of the common
one) just watches the TTY accessed times, and if they stop moving
they kill the session.
Oh yeah, it's idled, the Idle Daemon.
-- Jim
___
busybox mailing list
busybox@busybox.net
Using busybox utilities, is their a way to list idle TTY sessions?
Is w part of BB? who also shows it. You have to infer
idleness yourself from the idle time field.
-- Jim
___
busybox mailing list
busybox@busybox.net
I have some rubbish code I've inherited and don't have time to rewrite,
which can spit out
tar file1 file2 file3
where each of the file names is up to 100 chars, and there could be up
to
2000 of them in theory.
This is what xargs is for. (Hint: use tar -r)
find glop | xargs
I've worked out that while the code uses full paths to move the files
about, it uses relative paths in the zip command.
so that's 2000 * 50 in the absolute worst case.
It would be nice to know what length of command might break busybox,
but
failing that I'll stick an xargs in the command line
The error, such as it is, is in the implementation of the gpio/export
proc handler. The Unix file paradigm is that there is no difference
in function between writing bulk data as individual bytes or not,
except for performance and interleaving. For those rare cases where
the blocking matters,
The 'errors' EBUSY and EAGAIN are _temporary_ conditions,
often the correct response is to try again. (Even EACCESS,
ENOSPC, EEXIST, etc. could be considered temporary, depending
on circumstances, and a delayed retry could be considered the
right thing to do. Not commonly, of course.) Nowhere I
+/* Wait up to 5 seconds for the output buffer to drain */
+signal(SIGALRM, record_signo);
+alarm(5);
+tcdrain(STDIN_FILENO);
+alarm(0);
+signal(SIGALRM, SIG_DFL);
How does this work? Normally plain signal sets SA_RESTART and won't be
interrupting. You need sigaction
As far as I can tell, a proper version of
those program should not have any of the 1989 code still in it. Call
stty to set the terminal parameters, wait for somebody to hit enter,
maybe cat /etc/issue, then run the login command.
What else does it do?
One of the big jobs of getty (which didn't
No, this is while starting up, so we don't want to exit. The only
reason
for the alarm() is that tcdrain() might hang because of flow control
issues according to Denys, and if that happens we just want to fall
through and tcflush().
Forgive my lack of paying attention, but then what is the point
This thread started by Michal, who's trying to use a very slow
serial-over-jtag setup on microblaze, and had issues with characters
getting lost when getty started up (because of the tcflush), so we
wanted to add a tcdrain() instead.
A design problem? Why even issue the tcflush(stdout) (in
I'm just trying to point out that it seems to me that
the iceberg has knocked a big ol' hole in the side of
the ship, the deck chair placement isn't really going
to matter in the end.
There's a fundamental conflict between how the serial
port is being used in this scenario, versus how the
getty
To put it another way, sessions begin with getty.
One of its jobs is to ensure that there's no leftover
crap from a previous session that could hang over and
cause problems for the next one. (Think malicious
user queuing nasty things up on the serial port and
then logging out, in an environment
That is, it takes more than 20 seconds to transmit the buffer contents
... so that 1 second delay doesn't make much difference.
Exactly why trying to fix this system-specific problem
within getty itself is doomed to failure. His _system_
design is incorrect, if there's an important message
to
1 - 100 of 230 matches
Mail list logo
