Hi All,
everything comes to an end. Looks like my active development has reached
this end.
After a long and hard phase of decision I'm going to stop all of my
development work, not only for Busybox, for all projects. The reasons
for this are difficult, have just cumulated and don't belong
Posting the previous message to this list was unintentional ... sorry
for the noise!
--
Harald
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Stromverbrauch und niedrigerer Geräuschentwicklung.
Lediglich beim Bedarf für hochperformante Spiele- und
Grafik-Anwendungen, rate ich von derartigen Rechnern ab.
Mit freundlichen Grüßen
Harald Becker
___
busybox mailing list
busybox@busybox.net
http
On 02.04.2015 10:17, Ron Yorston wrote:
Harald Becker wrote:
... but I can't find the location in BB ash.c, where this \w is replaced
with the directory name :( ... (any hint?)
libbb/lineedit.c
Thanks, I stumbled on this at the same moment your message came in ...
and the separation
On 02.04.2015 09:28, Denys Vlasenko wrote:
Yes, bash shows that, but the *real* getcwd system call
returns /hdd1/test in this case.
You *can't* have a symlink as a current directory.
It's just not possible in Linux.
So just modify santosh's question:
Why can't we use and display the same
On 02.04.2015 10:34, Harald Becker wrote:
I don't know how to fix this.
Suggesting:
adding an extra parameter to read_line_input()
read_line_input(..., char *cwd_buf, ...)
propagating this to parse_and_put_prompt()
(removing the local variable of same name)
parse_and_put_prompt(..., char
On 02.04.2015 11:35, Ron Yorston wrote:
Harald Becker wrote:
Another similar case I've encountered is with the home directory.
The shell respects HOME in performing tilde expansion but lineedit
doesn't have access to the shell variable so uses getpwuid when
trying to display '~' in the prompt
I apologize, wrong translation, ...
On 20.03.2015 15:03, Harald Becker wrote:
Anyway shall confsh *not break* the KISS principal, Busybox is
following, *not wasting* resources otherwise useless, and *not build*
any specific system setup operation into the binary code.
s /otherwise useless
Hi !
*Intention:*
My original intention was (beside geting netlink operation), to add some
extensions to mdev, to have the ability to do a simple table driven
one-shot startup of the device file system.
The same extensions would also allow to bring up the other virtual file
systems, at no
On 20.03.2015 21:28, V.Krishn wrote:
The concept of a simple netlink reader daemon seems nice.
But would seem extra to having another reader that reads this reader.
The concept of whole /sys tree is being re-done, even if its just not
visible(memory). I could add/suggest few changes.
Please
On 18.03.2015 10:42, Didier Kryn wrote:
Long lived daemons should have both startup methods, selectable by a
parameter, so you make nobodies work more difficult than required.
OK, I think you are right, because it is a little more than a fork:
you want to detach from the controlling
On 18.03.2015 15:50, Alexis Guilloteau wrote:
After looking at the help of the ftpd function in busybox i know that
the main function is to create an anonymous ftp server so i was not
surprised with the lack but do you think there would be a solution for
that ?
Busybox ftpd is an anonymous
Hi Laurent !
Note that events can still be lost, because the pipe can be broken
while you're reading a message from the netlink, before you come
back to the selector; so the message you just read cannot be sent.
But that is a risk you have to take everytime you perform buffered IO,
there's no
Hi Laurent !
On 18/03/2015 18:08, Didier Kryn wrote:
No, you must write to the pipe to detect it is broken. And you won't
try to write before you've got an event from the netlink. This event
will be lost.
On 18.03.2015 18:41, Laurent Bercot wrote:
I skim over that discussion (because I
Hi Didier,
On 17.03.2015 19:00, Didier Kryn wrote:
The common practice of daemons to put themselves in background and
orphan themself is starting to become disaproved by many designers. I
tend to share this opinion. If such a behaviour is desired, it may well
be done in the script (nohup),
Hi Timo !
On 16.03.2015 07:23, Timo Teras wrote:
My take on this is that you are designing an abstract server to be
usable by several things. However, in our case it would be used only
by one thing. Thus adding complexity by introducing one more
component than needed. Not everyone wants to use
On 16.03.2015 06:09, Isaac Dunham wrote:
Aren't there any mount options for the filesystem type to set the default
permissions? Ahh, looks like there left such things out :(
-o mode?
Don't have any experience with mqueue, (some) other virtual file systems
have an option to set the mode.
On 16.03.2015 08:16, Natanael Copa wrote:
This give me exactly what I am interested in: a hotplug handler that is
fast while keep memory consumption at a minimal during long periods
with no events.
This is the essential of your message, I would give *you* the expected
result, but not to
On 16.03.2015 09:19, Natanael Copa wrote:
I am only aware of reading kernel events from netlink or kernel hotplug
helper.
Where as I'm trying to create a modular system, which allows *you* to
setup a netlink usage, *the next* to setup hotplug helper usage (still
with speed improvement, not
On 16.03.2015 21:30, Natanael Copa wrote:
Does it exist systems that are so old that they lack hotplug - but at
same time are new enough to have sysfs?
Oh, yes! Mainly embedded world.
I suppose it would make sense for kernels without CONFIG_HOTPLUG but I
would expect such systems use highly
On 16.03.2015 22:25, Didier Kryn wrote:
I had not caught the point that you wanted it a general purpose
tool - sorry.
It's a lengthy and complex discussion, not very difficult to miss
something, so no trouble. Please ask, when there are questions.
The netlink reader is a long lived
On 16.03.2015 18:13, Harald Becker wrote:
This is the essential of your message, I would give *you* the expected
result, but not to everybody else.
Sorry, bad typo :( - s /I/it/
This is the essential of your message, *it* would give *you* the
expected result, but *not* to *everybody* else
On 16.03.2015 19:49, Natanael Copa wrote:
netlink reader | tee /dev/ttyX | device operation handler
This looks good to me.
If you want avoid that this netlink reader in your example is in memory
at all times, then feel free to use my netlink socket activator to
activate it. Otherwise, please
On 15.03.2015 06:01, Isaac Dunham wrote:
the fstab approach has one big cave-eat, which got me awy from that idea: he
format of fstab does not allow to specify the owner, group and permissions
of newly created mount points, but if you like / need to do some kind of
Do you mean as in the
On 14.03.2015 03:40, Laurent Bercot wrote:
What would you do if your kid wanted to drive a car but said he
didn't like steering wheels, would you build him a car with a
joystick ?
... [base car with wheel steering module replaceable by a joystick
module] ...
... and the next one coming
On 14.03.2015 03:40, Laurent Bercot wrote:
- for reading: having several readers on the same pipe is the land
of undefined behaviour. You definitely don't want that.
... just for the curiosity:
On most systems it is perfectly possible to have multiple readers on a
pipe, when all readers
On 15.03.2015 14:29, Natanael Copa wrote:
You hacked a solution, for the mechanism of your preference, throwing
out those who want to use one of the other mechanisms ...
this is forcing others to do it your way?
The RFC in subject means request for comments, not I force you do it
my way.
I
On 15.03.2015 20:06, Laurent Bercot wrote:
What most systems do in practice is irrelevant. There is no guarantee
at all on what a system will do when you have multiple readers on the
same pipe; so it's a bad idea, and I don't see that there's any room for
discussion here.
My lead in was:
On 15.03.2015 20:06, Laurent Bercot wrote:
The behavior of multiple concurrent reads on the same pipe, FIFO,
or terminal device is unspecified.
That is, you can't predict, which process will get the data, but each
single read operation on a pipe (private or named), is done atomic.
Either
Hi James!
1) Why argue over something that has already been admitted?
It does not bolster your argument and it does not put in you
a good light.
Keep cool, I know the fears of Laurent.
There are to many stupid programmers out there, who would try to add
something like that into
So, as I'm not in write-only mode, here some possible alternatives, we
could do (may be it shows better, how and why I got to my approach):
1) netlink with a private pipe to long lived handler:
establish netlink socket
spawn a pipe to handler process
write a netlink, no timeout message
On 16.03.2015 00:53, Isaac Dunham wrote:
Just to clarify: this is NOT a feature I came up with.
I found it documented in the util-linux mount manpage:
x-*All options prefixed with x- are interpreted as comments or
Yes I know that x-* mount options approach, but I don't see it
Hi Isaac !
On 14.03.2015 08:10, Isaac Dunham wrote:
Basic concept is that it creates a fifo, and treats the success of mkfifo
as a lock to determine whether it's the daemon or a writer.
If it's the daemon, it will
fork;
in the child:
exec the parser with the fifo as stdin
in the parent:
On 14.03.2015 03:40, Laurent Bercot wrote:
Hm, after checking, you're right: the guarantee of atomicity
applies with nonblocking IO too, i.e. there are no short writes.
Which is a good thing, as long as you know that no message will
exceed PIPE_BUF - and that is, for now, the case with
Part of the information hopped to a different thread, so it is possibly
better to split this question of to a separate thread:
For those who want to use the kernel hotplug helper mechanism, the
netlink interested are not affected by this.
The Problem:
The kernel spawns a separate process
On 13.03.2015 16:53, Natanael Copa wrote:
I have the feeling (without digging into the busybox code) that making
mdev suitable for a longlived daemon will not be that easy. I suspect
there are lots of error handling that will just exit. A long lived
daemon would need log and continue instead.
Hi James !
On 13.03.2015 20:33, James Bowlin wrote:
On Fri, Mar 13, 2015 at 02:07 PM, Harald Becker said:
xdev -f
- starts up the fifo manager, if none running
(manual use is special purpose only)
[snip]
xdev -n
- select the netlink mechanism and start daemon
(auto
On 13.03.2015 23:33, Laurent Bercot wrote:
On 11/03/2015 08:45, Natanael Copa wrote:
With that in mind, wouldn't it be better to have the timer code in
the handler/parser? When there comes no new messages from pipe
within a given time, the handler/parser just exists.
I've thought about that a
On 13.03.2015 21:32, Michael Conrad wrote:
Are you suggesting even the netlink mode will have a process reading the
netlink socket and writing the fifo, so another process and can process
the fifo? The netlink messages are already a simple protocol, just use
it as-is. Pass the
You got the
Hi,
my original intention was to replace mdev with an updated version,
but as there where several complains which told they like to continue
using the the old suffering mdev, I'm thinking about an alternative.
... but the essential argument came from James, fail save operation.
In my last
On 13.03.2015 21:43, Laurent Bercot wrote:
Except you have to make the writes blocking, which severely limits
what the writers can do - no asynchronous event loop. For a simple
cat-equivalent between the netlink and a fifo, it's enough, but
it's about all it's good for. And such a
On 13.03.2015 00:05, Michael Conrad wrote:
On 03/12/2015 04:32 PM, Harald Becker wrote:
On 12.03.2015 19:38, Michael Conrad wrote:
On 3/12/2015 12:04 PM, Harald Becker wrote:
but that one will only work when you either use the kernel hotplug
helper mechanism, or the netlink approach. You drop
On 13.03.2015 10:30, Guillermo Rodriguez Garcia wrote:
There are many configuration options in BB that must be defined at
build time. I don't see why this one would be different.
You can activate both as the default (with cost of some byte overhead of
code size), and let the user of the
On 13.03.2015 10:52, Natanael Copa wrote:
Crazy idea:
have a netlink listener/handler that is installed in
/proc/sys/kernel/hotplug.
On startup it will set up a netlink listener and remove itself from
/proc/sys/kernel/hotplug so all subsequent events comes via netlink.
Read events from
On 13.03.2015 11:51, Laurent Bercot wrote:
I think that adding hotplug helper management in a hotplug helper
needlessly complicates things.
Complicate? Yes!
Needless? I doubt!
Needless in your eyes? Needless in my eyes? Sure!
... but others may answer it different.
So why bother? With a
On 13.03.2015 12:41, Michael Conrad wrote:
On 3/13/2015 3:25 AM, Harald Becker wrote:
This is splitting operation of a big process in different threads,
using an interprocess communication method. Using a named pipe
(fifo) is the proven Unix way for this ... and it allows #2 without
blocking
On 13.03.2015 12:29, Michael Conrad wrote:
On 3/13/2015 3:25 AM, Harald Becker wrote:
1 - kernel-spawned hotplug helpers is the traditional way,
2 - netlink socket daemon is the right way to solve the forkbomb
problem
ACK, but #2 blocks usage for those who like / need to stay at #1 / #0
On 13.03.2015 14:20, Didier Kryn wrote:
There are interesting technical points in this discussion, but it
turns out to be mostly about philosophy and frustration.
ACK :(
Hotplug is KISS, it is stupid, maybe, but it is so simple that you
can probably do the job with a script. The
On 13.03.2015 15:46, Michael Conrad wrote:
I thought pseudocode would be clearer than English text, but I suppose
my pseudocode is still really just English... Maybe some comments will
help.
You can't fix the suffering of your code with some comments ... beside
that, it looks like you
On 11.03.2015 17:24, Laurent Bercot wrote:
On 11/03/2015 17:10, Harald Becker wrote:
And what is wrong with a long lived daemon?
Ok, what I see is brain damaged developers writing big monolithic
long lived daemons, which suck up tons of memory and / or cpu power
:( ...
... this is not what I
Interrupts ... no trouble, everybody agree you need only one unblocked
interrupt source, but never ask for the detail which one ... :)
Hi Laurent !
I'm sorry if I came across as dismissive or strongly opposed to the
idea.
It was not my intent. My intent, as always, is to try and make
Hi Isaac !
On 12.03.2015 02:05, Isaac Dunham wrote:
I just don't think you're quite thinking through exactly what this means.
In which sense? Let me know, what I got wrong. I'm a human, making mistakes,
not a perfect machine.
It seems like you want to force everyone who uses mdev to use a
Hi !
To Michael:
Don't be confused, Natanael provided an alternative version to achieve
the initial device file system setup (which isn't bad, but may have it's
cons for some people on small resource constrained systems of the
embedded world). So I left it out for clarity ... but still may
Hi Laszlo !
So why don't you write such a binary wrapping busybox then and other
things? I think KISS principle still ought to be alive these days.
Not to mention, Denys already cannot cope with the maintenance the
way that it would be ideal. For instance, some of my IMHO serious
bugfixes are
Hi Natanael !
My point is that a long lived daemon that stays there 5 hours after
the last hotplug event is currently unavoidable unless you are ok
with one fork/exec for every event.
Why not logical splitting the function?
- one listener which is gathering data, and forward sanitized
Hi Natanael !
I assume that you are talking about named pipes (aka fifos)
http://en.wikipedia.org/wiki/Named_pipe
Ack, fifo device in the Linux / Unix world.
Why do you need a hotplug helper spawned by kernel when you have a
netlink listener? The entire idea with netlink listener is to
Hi Laurent !
Out of curiosity: what are, to you, the benefits of this approach ?
What are the benefits of preferences? ... good question!? ;)
Does it actually save you noticeable amounts of RAM ?
May be a few bytes ... noticeable? what is your level to noticeable
here? ... otherwise I
Hi Denys !
mdev rules are complicated already. Adding more cases
needs adding more code, and requires people to learn
new mini-language for mounting filesystems via mdev.
Think about it. You are succumbing to featuritis.
...
This is how all bloated all-in-one disasters start.
Fight that
On 11.03.2015 16:34, Laurent Bercot wrote:
On 11/03/2015 14:02, Denys Vlasenko wrote:
But that nldev process will exist for all time, right? That's not
elegant.
Ideally, this respawning logic should be in the kernel.
...
Needing daemons to answer notifications from userspace processes
or
Hi William !
On 11.03.2015 17:03, William Haddon wrote:
I suppose it's time to dig out code from the secret archives of my
secret lair again. Someone named Vladimir Dronnikov called this ndev
and proposed it as a patch to Busybox in 2009. I dug it out and
separated it from Busybox, and probably
Hi Isaac !
Agreed, whole-heartedly.
I just don't think you're quite thinking through exactly what this means.
In which sense? Let me know, what I got wrong. I'm a human, making
mistakes, not a perfect machine.
Agreed.
But I would include hotplug daemons under etc.
I used etc. so add
On 11.03.2015 22:44, Michael Conrad wrote:
What specifically is the appeal of a third approach which tries to
re-create the kernel netlink design in user-land using a fifo written
from forked hotplug helpers?
You mix things a bit.
My approach allows to either using netlink or kernel hotplug
Hi Michael !
On 11.03.2015 22:44, Michael Conrad wrote:
I'm interested in this thread, but there is too much to read. Can you
explain your reason in one concise paragraph?
One paragraph is a bit to short, my English sucks, but I try to
summarize the intention of my approach in compact steps
Hi Laurent !
1) Starting up a system with mdev usually involves the same steps to
mount proc, sys and a tmpfs on dev, then adding some subdirectories
to /dev, setting owner, group and permissions, symlinking some
entries and possibly mounting more virtual file systems. This work
need to be
Hi,
getting hints and ideas from Laurent and Natanael, I found we can get
most flexibility, when when try to do some modularization of the steps
done by mdev.
At fist there are two different kinds of work to deal with:
1) The overall operation and usage of netlink
2) Extending the mdev.conf
Hi Dallas !
Hi Harald, I was sort of expecting a mdev scan to discover and create
device nodes for usb.
Sounds like I need some rules defined in /etc/mdev.conf. I just have
a default one.
What consider you a default one? There are so many distros and systems
out in the wild, even the
Hi Natanael !
I am interested in a netlink listener too for 2 reasons:
- serialize the events
- reduce number of forks for perfomance reasons
My primary intentions.
That is, I want to auto fork a daemon which just open the netlink
socket. When events arrive it forks again, creating a
Hi !
On 08.03.2015 13:45, Guillermo Rodriguez Garcia wrote:
I think that it is just the numbers that are wrong as the text
explicitly says that steps 4-6 must be executed before the previous
code snippet (so 4-6 would actually be run before 1-3)
Yes! After additional studying of the text I
Hi !
I just stumbled about a disordering of operations in docs/mdev.txt:
---cut-here---
Basic Use
...
[0] mount -t proc proc /proc
[1] mount -t sysfs sysfs /sys
[2] echo /sbin/mdev /proc/sys/kernel/hotplug
[3] mdev -s
Alternatively, without procfs the above becomes:
[1] mount -t sysfs sysfs
Hi,
I'm currently in the phase of thinking about extending the functionality
of mdev. As here are the experts working with this kind of software, I
like to here your ideas before I start hacking the code.
I like to focus on the following topics:
1) Starting up a system with mdev usually
Hi Denys !
killall matches by /proc/PID/exe too.
Because some applets use a trick where they re-execute
themselves by execve(/proc/self/exe).
When you do that, /proc/PID/comm field gets set to string exe :(
Thus, matching by comm will fail to find a process
started this way.
... but here
Hi Denys !
Problem means it may make diagnosing other problems a hell.
Why is it hell? strace -p1 works.
If you have a working strace ...
... or in other words: Do you have a working Busybox applet for this?
You are right, I do not use init. Respawn on error is not the only,
or the
Hi Denys !
Unfortunately, there is no commonly agreed definition of
program named FOO.
... but standard usage cases should be acted on correct:
Think of:
ln -s /bin/Busybox ntpd
ln -s /bin/Busybox syslogd
ln -s /bin/Busybox klogd
ntpd ...
syslogd ...
klogd ...
Busybox killall ntpd
...
Hi Joshua !
Doesn't ntpd already use adjtimex to make that correction?
That would be great!
It was about 20 years ago, I used adjtimex to correct the clock of some
systems with no permanent Internet connection. Since this I did not look
to close to the changes that have gone to the time
Hi !
I appreciate that you would like to know why this isn't working but
I'm really not too keen on rebooting the device several times a day
when my original script seems to be working fine.
This is your decision, I fully understand your concerns. Just come back,
when you have need for this
Hi !
As you already note, the kernel does this update of the hardware clock,
as long as ntpd gets a synchronized clock.
Beside this, an endless loop is no problem:
#!/bin/sh
# the actual loop as a shell function
clock_update_loop()
{
while true
do
sleep 3600
hwclock -w
Hi Denys!
On 02.09.2014 15:52, Denys Vlasenko wrote:
$ busybox ntpd --help
BusyBox v1.22.1 (2014-02-01 19:25:19 CET) multi-call binary.
Usage: ntpd [-dnqNwl] [-S PROG] [-p PEER]...
NTP client/server
-dVerbose
-nDo not daemonize
-qQuit after clock is set
-N
Hi Joshua !
It's also interesting that busybox false --help behaves completely
differently
depending on whether it's invoked from within a busybox shell or not:
This is wrong! You called different versions, not Busybox false.
* invoking false as an ash builtin bypasses the --help
Hi !
Actually, the hwclock time is what's inaccurate
:-( ... bad hardware!
That is very interesting but since this system is always connected to the
Internet, I'm not sure I need to be that concerned about the hardware clock.
If your system is always connected to a functioning Internet
Try this one ...
start() {
echo -n Starting ntpd:
/usr/sbin/ntpd -p north-america.pool.ntp.org echo OK || echo
failed
}
Are you sure your ntpd (a symlink to /bin/busybox) lives in /usr/sbin ?
Well, I had nothing to do with building this system so I have no idea why
the formal correct
root at box:~ busybox false --help
BusyBox v1.22.1 (2014-08-28 18:55:30 EDT) multi-call binary.
Usage: false
Return an exit code of FALSE (1)
root at box:~ echo $?
0
root at box:~ false --help
root at box:~ echo $?
1
This shows me, your false is not same as Busybox internal false. You are
seems to be this busybox one 8-):
How can that be?
root@luxusAsus:~ which false
/bin/false
root@luxusAsus:~ which busybox
/bin/busybox
root@luxusAsus:~ ls -la /bin/false
lrwxrwxrwx1 root root 7 Aug 29 16:06 /bin/false - busybox
Ok!
root@luxusAsus:~ false --help
root@luxusAsus:~ type false
false is a shell builtin
Ohps!
# thats an explanation! 8-)
Indeed! :-)
... but this tells nothing about which return code
false --help
shall give.
IMO to display the usage information with --help is a successful
execution and shall return 0 as other
Hi Alfonso !
./foobar
./hello
killall foobar
also hello is killed
Did you verify that hello exited due to a signal from killall?
When a process exits the shell does not always display the information
immediately. Before display of next command prompt all job processes
which exited
Hi Alfonso !
ln -s foobar hello
I overlooked this. Sorry!
./foobar
./hello
This way you indeed start the same application twice. Especially if they
are shell scripts or something similar, it is very hard to distinguish
with which name they got started. See what ps or top say for those
Hi Alfonso !
See what ps or top say for those two jobs.
You did not give the information from my question.
busybox killall foobar
My Busybox killed foobar, not hello ... just tested!
So you indeed need to look for more detail, what is listed for the two
active processes.
--
Harald
Hi Alfonso !
I just wanted to know if it is a will or just happens in
find_pid_by_name.
The manpage says, killall shall send the signal to all processes running
the command. In fact is, you run the same command twice, when you do
this symlinking. As different kernel versions provide
Hi Alfonso !
I looked in the source for Busybox killall. It compares the value of the
comm field to determine which command is running. So give the /proc
field values for comm, cmdline and status of your processes, please.
--
Harald
___
busybox
Hi Alfonso !
Hi Denys !
This is suspicious. killall shall not kill both processes ...
./foobar
cat /proc/19618/comm
foobar
cat /proc/19618/cmdline
./foobar
cat /proc/19618/status
Name: foobar
./hello
cat /proc/19669/comm
hello
cat /proc/19669/cmdline
./hello
cat /proc/19669/status
Hi !
console::respawn:/sbin/getty -L 115200 ttyS0 vt100
This is a special Busybox feature. BB uses the id field to specify a tty
device, used to start the inittab command. If the device open fails, the
inittab line is skipped.
From examples/inittab:
# id: WARNING: This field has a
But I didn't know this. So it seems that if I use console as the id,
the device open succeeds when the system boots with console=ttyS0 but
fails when booting with console=null (not sure why -- shouldn't it be
possible to open /dev/null ?).
Have not looked into code, but I ought it depends on
Hi Denys !
If that open fails, then respawning will not be done.
Actually I'm testing this and it seems that init keeps spawning child
processes forever, every second. Inside run(), vfork succeds but then
the device open fails and the child process _exits().
Is there a way to have init
Hi Denys!
If that open fails, then respawning will not be done.
Actually I'm testing this and it seems that init keeps spawning child
processes forever, every second. Inside run(), vfork succeds but then
the device open fails and the child process _exits().
Is there a way to have init
Denys !
I don't like special-casing exit code values.
The proper fix is to open the file in the parent, before fork.
Then the failure can be detected in the parent.
This patch not only disables entries due to open failure of the console,
it also disables endless respawning of processes
Denys !
What if /dev/FOO does not exist YET? (E.g. USB-based serial TTY).
What if execve fails because /usr/bin/BAR does not exist YET?
Both cases can be solved when startup code send a SIGHUP to init when
all this stuff is available (at end of rc scripts do kill -SIGHUP 1)
Not to talk
Denys !
My argument is that before adding code, it makes sense to ponder
whether we really have a real problem here.
Do you really insist on this endless respawning NOT BEING A BUG???
I don't understand your stand point.
If one respawn per second a big problem? I'm not sure.
Problem
Hi !
I suggest doing it the simple style ...
#!/bin/sh
cat ~/.xmltv/tv_grab_file.xmltv
... thats the only action I can see. The rest looks more someone tried
to obfuscate the simplicity of the action, or did I miss something?
Harald
___
busybox
Hi Denys,
my new system gets to a usable state, so I'm able to do more then just
writing mails ...
4) applet printf, string formats %Ns
Does this N mean character positions or bytes. The underlying C printf used
to work with bytes for decades. The man page talks about character
positions,
Hi Dietmar!
On 14.08.2014 08:21, dietmar.schind...@manroland-web.com wrote:
These do not work if char is signed.
You are right, I missed the type casts ... sorry
size_t utf8len( const char* s )
{
size_t n = 0;
while (*s)
if ((unsigned char)(*s++ ^ 0x40) (unsigned char)0xC0)
Hi Rich!
You say this, but libbb/unicode.c contains a unicode_strlen calling
this complex mb to wc conversion function to count the number of
characters. Those multi byte functions tend to be highly complex and
slow (don't know if they have gone better). For just UTF-8, things
can be
1 - 100 of 538 matches
Mail list logo
