On 2014-03-19 01:28, j...@jodybruchon.com wrote:
> Running 'make distclean' does not remove various generated files in the "docs"
> directory. This has frustrated me when trying to make patches against BusyBox,
> as I cannot clean the folders properly without manually deleting files. The
> attached
Running 'make distclean' does not remove various generated files in the "docs"
directory. This has frustrated me when trying to make patches against BusyBox,
as I cannot clean the folders properly without manually deleting files. The
attached patch adds these generated docs to the "make distclean"
This is my latest patch to add 'u' (Undo) command support to BusyBox vi and it
is a major improvement over the previous two.
Improvements over v2:
* Seems to work with all editing functions I could test
* Find-and-replace undo now works; can reverse e.g. :1,3 s/foo/bar/
* Friendly constants for un
On Tue, Mar 18, 2014 at 5:41 PM, Jody Bruchon wrote:
> On 3/18/2014 10:51 AM, Jody Bruchon wrote:
>>
>> Out of an interest in seeing this feature, I'm looking at vi.c
>
>
> I've started implementing the "undo" function; it looks to be easier than I
> expected now that I have a feel for the way the
On Wed, Mar 19, 2014 at 03:37:25AM +, Laszlo Papp wrote:
> On Tue, Mar 18, 2014 at 10:46 PM, Xabier Oneca -- xOneca
> wrote:
> > Hello Laszlo,
> >
> > 2014-03-18 22:28 GMT+01:00 Laszlo Papp :
> >>> If you want a configuration file
> >>> only for the time servers, this script will give you co
On Tue, Mar 18, 2014 at 10:46 PM, Xabier Oneca -- xOneca
wrote:
> Hello Laszlo,
>
> 2014-03-18 22:28 GMT+01:00 Laszlo Papp :
>>> If you want a configuration file
>>> only for the time servers, this script will give you compatibility to the
>>> ntp.org config file:
>>> #!/bin/sh
>>> NTPD_OPTIONS=
On Tue, Mar 18, 2014 at 10:30 PM, Xabier Oneca -- xOneca
wrote:
> Hello,
>
> 2014-03-18 22:17 GMT+01:00 Ralf Friedl :
>>> > Usually scripts in/etc/init.d use /etc/default/* as config values
>>>
>>> > (some distros, even using them as main config files). The scripts that
>>> > Laszlo posted fit t
On Tue, Mar 18, 2014 at 10:03 PM, Laurent Bercot
wrote:
> On 18/03/2014 21:28, Laszlo Papp wrote:
>
>> Exactly the opposite. You really missed the point of this thread. The
>> whole point about configuration file is to unify it, for me at least.
>
>
> But what makes you think a configuration file
On Tue, 18 Mar 2014, Laszlo Papp wrote:
>
> I would really appreciate more respect here towards end users. No one
> is forcing anything.
You're barking at the wrong tree, Laszlo.
> The end users have raised their opinion how they would like to see
> your software behaving.
Who's the end user her
Hello Laszlo,
2014-03-18 22:28 GMT+01:00 Laszlo Papp :
>> If you want a configuration file
>> only for the time servers, this script will give you compatibility to the
>> ntp.org config file:
>> #!/bin/sh
>> NTPD_OPTIONS="..."
>> exec busybox ntpd $NTPD_OPTIONS $(sed -nre 's/^server *(.*)$/-p
>> \
Hello,
2014-03-18 22:17 GMT+01:00 Ralf Friedl :
>> > Usually scripts in/etc/init.d use /etc/default/* as config values
>>
>> > (some distros, even using them as main config files). The scripts that
>> > Laszlo posted fit that pattern.
>> Not quite; actually "/etc/default" is more like a Debian, et
On 3/18/2014 6:15 PM, Jody Bruchon wrote:
This code is in a "works for me" state but needs testing and refinement.
D'oh, I didn't test building without the undo feature enabled and missed
an #if/#endif. Apologies. Revised patch attached.
Also, there is an "unused parameter" warning if undo i
On 3/18/2014 6:15 PM, Jody Bruchon wrote:
As promised earlier, I have written undo support for BusyBox 'vi'.
I forgot to add my sign-off to this patch; please tack it on if
committed to Git.
Signed-off-by: Jody Bruchon
___
busybox mailing list
bu
As promised earlier, I have written undo support for BusyBox 'vi'.
This code is in a "works for me" state but needs testing and refinement.
I have not tested it on any other platforms than my computer. I have not
tested it under all possible configurations or scenarios, and there is
room for f
On Tue, Mar 18, 2014 at 01:43:43PM +0100, Harald Becker wrote:
> The Busybox ntpd applet get all information it needs via command
> line, so it doesn't need to read any config file.
I agree, it would be overlapping functionality and not needed.
A.
___
b
Laszlo Papp wrote:
On Tue, Mar 18, 2014 at 9:17 PM, Ralf Friedl wrote:
First, please either write your message below the quotes, or omit the
quotes. Especially don't quote parts that are not relevant to your message.
I have no idea what point you are trying to make in here, sorry, nor
do I car
On 18/03/2014 21:28, Laszlo Papp wrote:
Exactly the opposite. You really missed the point of this thread. The
whole point about configuration file is to unify it, for me at least.
But what makes you think a configuration file would unify the way
distributions run busybox ntpd more than the cu
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
htt
On Tue, Mar 18, 2014 at 9:17 PM, Ralf Friedl wrote:
> Hi Laszlo
>
> First, please either write your message below the quotes, or omit the
> quotes. Especially don't quote parts that are not relevant to your message.
I have no idea what point you are trying to make in here, sorry, nor
do I care ab
Hi Laszlo
First, please either write your message below the quotes, or omit the
quotes. Especially don't quote parts that are not relevant to your message.
Laszlo Papp wrote:
At least three people expressed that it is about convenience, a useful
one.
Well, all of them didn't provide a convinc
Hi Mike !
On 18-03-2014 15:12 Mike Dean wrote:
># Put your ntp nameservers here
To clarify: It's not a name server, it's a time server (NTP =
network time protocol).
... and what makes it difficult to write such things in a file,
use an sed filter to read that config into a script variable,
the
Actually, I didn't come to the list to ask for the feature. Someone else
came here to ask for it; I just seconded this person. You, much like
Harald, are blaming the deficiencies of your design decisions on your
users. The haughty attitude, from our standpoint, comes from you, not from
us. To s
Hi Mike !
> If adding the feature outright would bloat the system, you make
> it a configurable choice so that it won't add bloat where that
> bloat is unwelcome, but will aid those who value the
> convenience more than the space savings. You already have the
> means to do this easily, so why not
On 18/03/2014 20:29, Mike Dean wrote:
So the deficiency of your software can always be blamed on your software's
userbase? Sounds like a winning philosophy.
The fact that you still think using command-line arguments instead of
a config file is a "deficiency" shows that you are missing the po
On Tue, Mar 18, 2014 at 8:58 PM, Harald Becker wrote:
> Hi Laszlo !
>
>> ... If it is rejected, there will be some unhappier users.
>
> Beside you are not giving any arguments, you are at the wrong
> place.
Harald, there is a difference between "not giving any arguments" and
"giving a few that yo
Hi Andreas,
On Tue, Mar 18, 2014 at 8:41 PM, Andreas Oberritter
wrote:
> On 18.03.2014 21:11, Laszlo Papp wrote:
>> On Tue, Mar 18, 2014 at 7:59 PM, Xabier Oneca -- xOneca
>> wrote:
>>> Usually scripts in /etc/init.d use /etc/default/* as config values
>>> (some distros, even using them as mai
Hi Laszlo !
> ... If it is rejected, there will be some unhappier users.
Beside you are not giving any arguments, you are at the wrong
place. Again: Busybox is a set of tools which may be used to
build a small and simple system. Convince for users is the
job of system or distro maintainers, which
Laurent,
I am currently having difficulties to understand your reply. It seems
that you have skipped some of the previous emails. Both me and Mike
were suggesting a simple config parser without signals to see how it
goes, and add that later if really needed.
More importantly, as far as I understa
On 18.03.2014 21:11, Laszlo Papp wrote:
> On Tue, Mar 18, 2014 at 7:59 PM, Xabier Oneca -- xOneca
> wrote:
>> Usually scripts in /etc/init.d use /etc/default/* as config values
>> (some distros, even using them as main config files). The scripts that
>> Laszlo posted fit that pattern.
>
> Not q
On 18/03/2014 20:12, Mike Dean wrote:
So it's difficult to provide and document a configuration file like this?
It's not difficult.
But it conflicts with some of the goals of Busybox.
Parsing a config file has several drawbacks:
- It is much more complicated than reading command-line argum
On Tue, Mar 18, 2014 at 3:15 PM, Harald Becker wrote:
> Hi Mike !
>
> >... We work hard to make things easy for them. One of the
> >stumbling blocks our customers have had in the past is how to
> >configure ntpd to use their internal ntp servers. Helping them
> >with this usually results in gru
Hi Laszlo !
>Yet, it did not get any feedback from anyone yet. Hopefully, it
>is not getting lost in the noise.
Will try to hop on this tomorrow, to late for today ... saved
your original message.
--
Harald
___
busybox mailing list
busybox@busybox.net
Harald, I think you do not get the meaning of "convenience" in here as
it was meant.
Let me give you an example: sure, people can live without convenience.
The people had not needed computers for the 99.99% of the ages and
time, but that does not mean it does not make a difference in the
world
Hi Laszlo !
> At least three people expressed that it is about convenience, a
> useful one.
Any people arguing for your request, missed the explanation why
they can't live with the already available version and some
scripting. That is now one has given a real argument why it is
necessary to add e
Hi Mike !
>... We work hard to make things easy for them. One of the
>stumbling blocks our customers have had in the past is how to
>configure ntpd to use their internal ntp servers. Helping them
>with this usually results in grumbling about it being
>overcomplicated to perform what should be su
So it's difficult to provide and document a configuration file like this?
---
# Put your ntp nameservers here
# Example:
# nameserver ntp.busybox.net
nameserver ntp.example.com
nameserver ntp2.example.com
---
I can see that we'll be using the full version of ntpd on our distro.
You've fully con
On Tue, Mar 18, 2014 at 7:59 PM, Xabier Oneca -- xOneca
wrote:
> Hello all,
>
> I'm with Sven-Göran, Harald, Cristian, et al.
>
> I see the point of Harald that if the config file is implemented, then
> someone will want it to be reloaded whitout quitting the daemon, and
> what not! That's a lot
Just chiming in to support Harald.
Busybox provides a usable ntpd interface. Calling ntpd with the
suitable arguments is the job of the init scripts, not Busybox;
if people have trouble starting ntpd, it's the responsibility of
their distribution packagers, not of Busybox; if they are the
dist
On 3/18/2014 3:54 PM, Mike Dean wrote:
So you're telling me that a plain text script which takes more than 300 bytes
is a better solution than an option that could be configured out? But your
full text option, enabled by default, takes less than 300 bytes I suppose?
I'm not sure I follow. H
So you're telling me that a plain text script which takes more than 300 bytes
is a better solution than an option that could be configured out? But your
full text option, enabled by default, takes less than 300 bytes I suppose?
Sent from my iPhone
> On Mar 18, 2014, at 2:49 PM, Michael Conrad
Hello all,
I'm with Sven-Göran, Harald, Cristian, et al.
I see the point of Harald that if the config file is implemented, then
someone will want it to be reloaded whitout quitting the daemon, and
what not! That's a lot of (byte)code!
Maybe Busybox could be shipped with an example init script fo
I couldn't agree more, Laszlo.
Sent from my iPhone
> On Mar 18, 2014, at 2:44 PM, Laszlo Papp wrote:
>
> Sven, you totally missed the whole point of the thread in my opinion.
> At least three people expressed that it is about convenience, a useful
> one.
>
> On Tue, Mar 18, 2014 at 7:36 PM, S
On 3/18/2014 3:09 PM, Mike Dean wrote:
Helping them with this usually results in grumbling about it being
overcomplicated to perform what should be such a simple task.
IMHO, the plethora of unix config file syntaxes are much harder to learn
than reading a quick manpage (or --help in this case)
Hi Laszlo !
>> No, it's not really an argument for anything. You asked me if
>> I tried calling "busybox ntpd --help", and I was responding
>> with what I did and my results. If anything, it'd be an
>> argument to update
>> http://www.busybox.net/downloads/BusyBox.html.
>
>That would be a really
Sven, you totally missed the whole point of the thread in my opinion.
At least three people expressed that it is about convenience, a useful
one.
On Tue, Mar 18, 2014 at 7:36 PM, Sven-Göran Bergh
wrote:
> Hi Mike et.al,
>
> I have just finished reading through this thread and yet I have not seen
Hi Bryan !
On 18-03-2014 19:10 Bryan Evenson wrote:
> If anything, it'd be an argument to update
> http://www.busybox.net/downloads/BusyBox.html.
Ok, first useful hint here, the Web-Page seams to be rather old.
The Busybox.html in the docs subdirectory (after build?) is much
more up to date an
Hi Mike et.al,
I have just finished reading through this thread and yet I have not seen
any substantial explanation _why_ BB should include this feature.
Both Harald and Cristian have suggested reasonable solutions for this.
The concept of sourcing a config file from an initscript is common pract
On Tue, Mar 18, 2014 at 7:10 PM, Bryan Evenson wrote:
> Harald,
>
>> -Original Message-
>> From: Harald Becker [mailto:ra...@gmx.de]
>> Sent: Tuesday, March 18, 2014 2:51 PM
>> To: Bryan Evenson
>> Cc: busybox@busybox.net; Rich Felker; Laszlo Papp; Adam Tkáč
>> Subject: Re: Ntpd config fil
Harald,
> -Original Message-
> From: Harald Becker [mailto:ra...@gmx.de]
> Sent: Tuesday, March 18, 2014 2:51 PM
> To: Bryan Evenson
> Cc: busybox@busybox.net; Rich Felker; Laszlo Papp; Adam Tkáč
> Subject: Re: Ntpd config file support
>
> Hi Bryan !
>
> >With my setup, busybox was not b
Harald,
I would but I'm busy porting existing device drivers to Device Tree and
writing some new drivers. Our last release used a kernel version that
didn't have Device Tree, so getting support for all the hardware on all of
our boards for this new kernel version is a substantial amount of work.
On Tue, Mar 18, 2014 at 6:51 PM, Harald Becker wrote:
> if usage of an applet is
> unclear, just ask ... if you need help to setup required
> scripts, just ask ...
Let us see if we can more productive then!
How about the following two files:
diff --git a/meta/recipes-core/busybox/files/busybox-
Hi Bryan !
>With my setup, busybox was not being compiled with the full
>usage messages,
A problem of your build system. The default config include the
full usage messages.
> so this just returns "ntpd: applet not found"
Why didn't you grab a precompiled default BB binary, just to do
the tests
Hi Laszlo !
> My question was more about a "start" config file parsing.
Which makes no sense, as it is mostly the time server address you
will pass in (and configure). Get your scripts right and you can
pass in your time server address(es) as much configurable as
you like. With no need to add any
Harald,
> -Original Message-
> From: Harald Becker [mailto:ra...@gmx.de]
> Sent: Tuesday, March 18, 2014 2:31 PM
> To: Bryan Evenson
> Cc: busybox@busybox.net; Rich Felker; Laszlo Papp; Adam Tkáč
> Subject: Re: Ntpd config file support
>
> Hi Bryan !
>
> On 18-03-2014 18:02 Bryan Evenson
Hi Mike !
On 18-03-2014 12:52 Mike Dean wrote:
>I just implemented such code for a project I'm working on, and I
>viewed it as pretty trivial.
So why don't you provide an example for a patch to implement the
function you request ... with full bloat check output and
description of benefits ... th
Hi Bryan !
On 18-03-2014 18:02 Bryan Evenson wrote:
>Harald had suggested an example startup script (I'm assuming
>under the examples/ directory of the Busybox source?). With a
>working example and an easy place to find the ntpd command line
>options, I'd probably give the Busybox-provided ntpd
> -Original Message-
> From: Rich Felker [mailto:dal...@aerifal.cx]
> Sent: Tuesday, March 18, 2014 1:12 PM
> To: Bryan Evenson
> Cc: Harald Becker; Laszlo Papp; busybox@busybox.net; Adam Tkáč
> Subject: Re: Ntpd config file support
>
> On Tue, Mar 18, 2014 at 01:59:37PM +, Bryan Evens
Yes, I agree with Mike that we do not need complex signal handling for
starter. My question was more about a "start" config file parsing. I
still stick by that it would be simple and useful to add (open, read,
get value, close), but that being said, I am fine with a contribution
directory entry, to
I just implemented such code for a project I'm working on, and I viewed it
as pretty trivial.
In any case, Busybox is king of going half way with features, so why not
make it just parse the config on startup and not worry about trapping
signals? If you do wish to implement signal handling, then a
On 3/18/2014 10:51 AM, Jody Bruchon wrote:
Out of an interest in seeing this feature, I'm looking at vi.c
I've started implementing the "undo" function; it looks to be easier
than I expected now that I have a feel for the way the buffer is handled
and should add very little actual code (thoug
Hi Mike !
> If there's code bloat from parsing a simple config file, then
> perhaps Busybox isn't well designed.
Same misunderstanding as Laszlo. It is not only parsing a simple
config file. AFAIK libbb has functions to do this. The problem
is, it makes no sense to blow up the BB binary size for
On Tue, Mar 18, 2014 at 01:59:37PM +, Bryan Evenson wrote:
> I'm also using ntpd with a Yocto Project based system, and I had
> switched to using the full ntp package instead of the Busybox
> supplied ntpd because of configuration. Within this build framework,
> I didn't see an easy way to adju
On Tue, Mar 18, 2014 at 04:44:22PM +0100, Bartosz Gołaszewski wrote:
> > I have such a directory on my systems (/mnt/tmpfs, 0755, with /tmp
> > actually being a symlink to /mnt/tmpfs/tmp, 1777). Some distributions
> > use an initramfs and create /lib/rw (ugh). Unfortunately, nothing is
> > standard
I haven't worked with the code, but to me, it looks like:
1. it's stuffing a pointer to the first index into the passed in array into
q
2. it's replacing any newlines in the string with nulls
3. it's calling a colon() function to execute the command mode command
associated with the string that was
On 2014-03-17, John Spencer wrote:
> when using busybox telnet to manually connect to some service like
> SMTP, it doesnt change the \n it receives into an \r\n sequence
> before it sends the line over the wire.
Then busybox telnet is broken. The conversion of line endings to/from
\r\n is not o
I think that adding this feature is an excellent idea. I don't understand
where all the resistance is. If there's code bloat from parsing a simple
config file, then perhaps Busybox isn't well designed. I don't know, I
haven't worked with it's code; perhaps I'm just used to the Linux kernel's
cod
Hi Laszlo !
>That is the fourth solution I see now in a raw... after Yocto,
>Buildroot and OpenWrt...
>
>This is what I was referring to. It is inconsistent across
>projects. :)
>
>That being said, it seems that Harald is objecting to this
>heavily for some reason (may be miscommunication between
> I have such a directory on my systems (/mnt/tmpfs, 0755, with /tmp
> actually being a symlink to /mnt/tmpfs/tmp, 1777). Some distributions
> use an initramfs and create /lib/rw (ugh). Unfortunately, nothing is
> standardized... Maybe we could use /dev ? Ha ha, only serious.
Is it necessary to us
On 3/18/2014 9:24 AM, Laszlo Papp wrote:
Hi,
do you plan to implement this feature any soon? It would be really
useful. Currently, it is a bit difficult to do undo in certain
scenarios when editing files on the embedded board.
Out of an interest in seeing this feature, I'm looking at vi.c and
That is the fourth solution I see now in a raw... after Yocto,
Buildroot and OpenWrt...
This is what I was referring to. It is inconsistent across projects. :)
That being said, it seems that Harald is objecting to this heavily for
some reason (may be miscommunication between us). Thereby, I will
Hi Laszlo !
>Yes, it is possible to do it without systemd, although pretty
>much everyone seems to be switching across, really, even Ubuntu
>itself.
... and I'm never going to use Ubuntu again, for there decisions.
>I have no idea why you would like to make it so complex. The
>config file is so
On Tue, 18 Mar 2014, Bryan Evenson wrote:
>
> How about a set of ntpd menuconfig options to build the command
> line? We could configure the default ntpd settings at build time,
> it wouldn't add anything to the size of the final ntpd binary.
How about using a resource file the initscript would s
By the way, I sent it a few months ago to the mailing list, but it has
not arrived. Any reason for that? I also tried to contact the mailing
list owner, but have never received any replies. :-(
It would be nice to avoid this in the future, so it would be nice to
know the reason. Nothing has change
All,
> -Original Message-
> From: busybox-boun...@busybox.net [mailto:busybox-
> boun...@busybox.net] On Behalf Of Harald Becker
> Sent: Tuesday, March 18, 2014 9:53 AM
> To: Laszlo Papp
> Cc: busybox@busybox.net; Adam Tkáč
> Subject: Re: Ntpd config file support
>
> Hi Laszlo !
>
> >Tha
On Tue, Mar 18, 2014 at 1:52 PM, Harald Becker wrote:
> Hi Laszlo !
>
>>That is not much of a difficulty today. Systemd can probably do
>>this for one.
>
> Not everybody like to use systemd ... I hate it and will NEVER
> use it on a system of mine!
Yes, it is possible to do it without systemd, al
Hi Laszlo !
>That is not much of a difficulty today. Systemd can probably do
>this for one.
Not everybody like to use systemd ... I hate it and will NEVER
use it on a system of mine!
>The main concern is not whether or not it is easy. It could be
>easy the same way to put it into the source code
Hi,
do you plan to implement this feature any soon? It would be really
useful. Currently, it is a bit difficult to do undo in certain
scenarios when editing files on the embedded board.
Cheers, L.
___
busybox mailing list
busybox@busybox.net
http://list
On Tue, Mar 18, 2014 at 1:24 PM, Harald Becker wrote:
> Hi Laszlo !
>
>>The idea is that I have an application on the embedded system
>>where the user can configure the ntp peer. The application would
>>then re-run and also enable the ntp daemon from busybox if it is
>>not yet done so.
>
> All tha
Hi Laszlo !
>The idea is that I have an application on the embedded system
>where the user can configure the ntp peer. The application would
>then re-run and also enable the ntp daemon from busybox if it is
>not yet done so.
All that is not part of Busybox. So you are free to put this to
your dis
Hi Harald,
I am working on an init script which I will submit soon to the Yocto
project if everything goes alright.
The idea is that I have an application on the embedded system where
the user can configure the ntp peer. The application would then re-run
and also enable the ntp daemon from busybo
Hi Laszlo !
>it seems that the ntpd util currently does not support config
>files.
The Busybox ntpd applet get all information it needs via command
line, so it doesn't need to read any config file. The config
files Zoltan mentioned are part of his distribution, not
Busybox. So what kind of config
Hi,
it seems that the ntpd util currently does not support config files.
Currently, it means that I need to work this around in Yocto for my
purposes, but as I see Zoltan Gyarmati here (*) also tried to do
similar things in buildroot.
Would it be acceptable to add such a feature? If yes, is anyon
Hi John !
>when using busybox telnet to manually connect to some service
>like SMTP, it doesnt change the \n it receives into an \r\n
>sequence before it sends the line over the wire. is there some
>workaround to make this possible ?
On older Unix systems (not Busybox) I used a simple approach
83 matches
Mail list logo
