On Wed, 2015-07-22 at 14:29 +0200, Laurent Bercot wrote:
I don't use alloca, but I'm a big fan of VLAs
Unfortunately VLAs are significantly less useful (IMO) because they have
block scope instead of function scope, like alloca().
___
busybox mailing
On Wed, 2014-08-13 at 19:23 +0200, Harald Becker wrote:
bash gives number of Unicode chars.
I just fixed both ash and hush to do the same.
bash seams to be the only shell which does this. So is this a
bash-ism?
The POSIX standard says that ${#var} give the length of variable var in
On Wed, 2014-08-13 at 13:52 -0400, Paul Smith wrote:
The POSIX standard says that ${#var} give the length of variable var
in characters. I can't find, offhand, a definition of characters
in the standard
D'oh! It was only in the most obvious place:
3.87 Character
On Fri, 2014-01-24 at 08:50 -0800, Isaac Dunham wrote:
On Thu, Jan 23, 2014 at 07:04:09PM +0100, Harald Becker wrote:
Hi,
for those who are interested: Gentoo seams to have updated POSIX
man pages (first Update since 2003).
Nothing really big: they just added the arm64 arch.
On Tue, 2013-03-12 at 12:35 -0400, q5sys wrote:
however when I try to start any other program, like another shell for
example, zsh, bash, etc. Busybox returns that the command is not
found.
Usually when I see this it means you're trying to run a 32bit
application on a system without runtime
On Sun, 2012-07-08 at 08:22 +0300, Eial Czerwacki wrote:
On 07/05/2012 06:41 PM, Paul Smith wrote:
If you can use a getent applet instead, and one is created and added to
busybox, that would be better for everyone of course.
Cheers!
offering me to use a applet that isn't even
On Thu, 2012-07-05 at 17:13 +0300, Eial Czerwacki wrote:
On 07/05/2012 02:03 PM, Laurent Bercot wrote:
but these bins are large, my applet adds at most 3kb to the total size.
My statically linked dnsip applet is 27 kB. This does not qualify as
large by any means on a full-fledged Unix
On Wed, 2012-07-04 at 08:07 +0300, Eial Czerwacki wrote:
does getent needs a valid host file in the system?
after viewing both host and getent I'm sure that host is exactly what
I've implemented. I don't think it is a good idea to base the
implementation on getent.
I didn't see your
On Wed, 2012-07-04 at 09:14 +0300, Eial Czerwacki wrote:
that is right but assuming /etc/hosts parsing is added, how can we be
sure that there isn't any changes in file format?
I don't understand what you mean. There's no need to add parsing
for /etc/hosts to anything. The library already has
On Tue, 2012-07-03 at 11:36 -0400, Joshua Judson Rosen wrote:
On 2012-07-03 10:58, ra...@gmx.de wrote:
So it might be a good idea for Eial to model this new applet on
glibc's getent command
I cannot find any reference to glibc's getent command, can you point
me to such reference?
On Wed, 2012-07-04 at 04:08 +0200, ra...@gmx.de wrote:
Hi Paul!
IMHO we shouldn't be inventing new applets for busybox.
...
Creating applets with no precedent in other UNIX/POSIX
systems is (again IMHO) not a good idea for busybox.
In principle you are right, but Busybox is used on
On Tue, 2011-07-19 at 17:08 +0200, Ralf Friedl wrote:
In coreutils df, one of the effects of the option -P is to output
everything in one line. This makes it much easier for a script to
parse the output of df.
I'd really love for this feature to be added to busybox df; I just had
to jump
On Mon, 2011-07-11 at 02:23 -0400, Mike Frysinger wrote:
On Mon, Jul 11, 2011 at 02:19, Laurent Bercot wrote:
http://www.busybox.net/FAQ.html#standards says:
portability to dozens of platforms is only interesting in terms of
offering a restricted feature set that works everywhere, not
On Thu, 2011-06-16 at 15:13 -0400, Rich Felker wrote:
On Thu, Jun 16, 2011 at 03:16:38PM -0400, Paul Smith wrote:
PS. Interestingly, there's a move afoot to remove newline from the set
of acceptable characters in a POSIX-compliant filename...
Do you have details on this? It's
On Wed, 2011-05-25 at 17:20 +0200, Harald Becker wrote:
In principle you are right, but it depends on the version of bash.
There exist two strategies which lead to different results in those
cases. Some shells run the last process in a pipe in the current shell
others the first process. If the
On Sat, 2011-05-21 at 20:46 +0200, Denys Vlasenko wrote:
See? According to this RFC, it's not an ASCIZ string.
At best, it may be a set of LASCII strings.
It may be even a set of something else than strings.
Nice :-/.
Can you send be an example of the DHCP packets which your server
emits?
Hi all.
I was using busybox 1.15.3, and configured my DHCP server to send a
userclass value of 'FOO' with the registration response. I use dnsmasq
and the dnsmasq config was:
dhcp-option-force=77,FOO
(option 77 decimal, or 0x4D, is the userclass option).
With busybox 1.15.3, this value was
On Tue, 2011-02-08 at 12:40 +, David Collier wrote:
Ah I've had another look at this
bash _allows_ the round brackets as in
func2 ()
{
}
but on further examination, they are apparently redundant syntax!
I'm not sure what you mean. The parentheses are definitely NOT
On Tue, 2011-02-08 at 03:02 -0800, Sven-Göran Bergh wrote:
- pushd popd, not in ash
But you can do simple:
cd /foo
cd -
This is not the same as pushd and popd. A workaround with aliases
may work though:
For shell scripts the simplest solution is often to use a
On Tue, 2011-02-08 at 18:31 +, David Collier wrote:
OK - I always thought that there was a fundamental incompatibility
between the syntax for bash functions and that for ash
But I couldn't recall the details when challenged above.
so bash has
function fred{}
or
fred(){}
On Mon, 2011-02-07 at 14:07 +, David Collier wrote:
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
On Wed, 2010-12-01 at 19:09 +, Chris Rees wrote:
Hi,
The use of malloc.h is a SYSVism, and the attached patch fixes for
FreeBSD at least!
http://www.bayofrum.net/~chris/patch-appletlib-c
If it needs reworking I'll do it; I'm likely to be sending a few soon
and I want them to be
On Mon, 2010-11-22 at 09:27 +0100, Bernd Petrovitsch wrote:
On Son, 2010-11-21 at 18:39 -0500, Paul Smith wrote:
On Mon, 2010-11-22 at 00:25 +0100, Cristian Ionescu-Idbohrn wrote:
Different shells (ash, dash, bash) handle the above in an unexpected
way. I would have expected a consistent
On Mon, 2010-11-22 at 18:55 +0100, Cristian Ionescu-Idbohrn wrote:
But, either way it doesn't change my answer since the question was why
different shells don't all treat local as a reserved word.
And, maybe not so. The question is:
local is a shell reserved word, isn't it?
On Thu, 2010-09-09 at 15:27 +0200, Denys Vlasenko wrote:
I am a bit concerned that I start to hate releases precisely because
pushing out a release gets more and more cumbersome.
Usually what I do is figure out the steps once, then write a makefile
rule or similar that does it for me. Then I
On Thu, 2010-05-20 at 08:40 +0200, Nils Carlson wrote:
I can't argue against bashisms, but neither can I argue for dashisms.
If we go posix shell compliant, then we should be posix shell
compliant, but posix shell complicance is very very restrictive so
this would be a real pain.
I don't
Hi all. I've just finished tracking down a weird problem on our system.
I can fix the top-level issue, but I'm trying to determine whether
there are any real bugs here (besides my error) or not.
We're using an intel-based embedded system running in a ramdisk with a
2.6.32.13 kernel, glibc, and
Definitely put me down in the camp that does NOT want to add a lot of
bash-specific features to the default shell.
The default shell should be POSIX, nothing more. Anything else runs the
risk of introducing incompatibilities with standard POSIX scripts,
resulting in failures!
For example, what
On Sat, 2009-10-24 at 17:21 +0200, Denys Vlasenko wrote:
There should be a way to shut up gcc in these places only
instead of pessimizing the code. At least I hope so.
I've not done any measurements, but it seems reasonable to me that the
(%s, string) form would be at least as efficient, if not
On Sat, 2009-04-18 at 01:52 -0700, Chris Plasun wrote:
On the board I run mount -t nfs 192.168.1.102:/home/na/nfstest
/nfstest but it eventually returns with the following error:
mount: RPC: Timed out
mount: nfsmount failed: Bad file descriptor
mount: Mounting
On Sat, 2009-04-18 at 18:53 +0100, Michael Abbott wrote:
On Sat, 18 Apr 2009, Paul Smith wrote:
On Sat, 2009-04-18 at 01:52 -0700, Chris Plasun wrote:
On the board I run mount -t nfs 192.168.1.102:/home/na/nfstest
/nfstest but it eventually returns with the following error:
mount
On Thu, 2009-03-12 at 15:56 +, Roy Marples wrote:
one thing I didnt find yet in any docu: how can I catch if a string is
entered instead of a number with read?
if ! printf %d $n /dev/null 21; then
echo You didn't enter a number
exit 1
fi
Alternatively:
case $n in
On Wed, 2008-11-19 at 18:01 +0100, Yann E. MORIN wrote:
Do not forget that back-ticks are not POSIX, while $() is.
Uh... what?!?! That's absolutely not true. Backticks are
unquestionably defined in the POSIX sh definition. They are not marked
as old or deprecated or anything similar.
It's
On Wed, 2008-11-19 at 19:12 +0100, Yann E. MORIN wrote:
What makes you say it's /far more portable than $()/ ?
Just because there are still shells out there that don't implement $()
(msh in busybox is one example, but also IIRC the Solaris /bin/sh falls
into this category).
On Tue, 2008-05-13 at 10:04 +0200, Bernhard Fischer wrote:
A testsuite is supposed to run in about any shell and with about any
test(1).
I've seen [ `echo one two` = one two ] fail because the first string
was not interpreted as one string (i.e. `something` to be safe).
And of course i've
On Sun, 2008-05-11 at 19:28 +0200, Cristian Ionescu-Idbohrn wrote:
NAME=$1
- [ -z $1 ] NAME=$2
+ [ -n $1 ] || NAME=$2
You can replace both these lines with:
NAME=${1:-$2}
___
busybox mailing list
busybox@busybox.net
On Mon, 2008-05-12 at 17:06 -0400, Paul Fox wrote:
[ -n = bar ]
just putting the args to test in double
quotes has always been enough for me.
Using quotes doesn't do anything here. The shell will strip them out
before invoking the test program (and if test/[ is builtin the shell
is
On Wed, 2008-05-07 at 09:53 +0200, Cristian Ionescu-Idbohrn wrote:
Good observation Paul. Still. Are 'true' and 'false' builtins in all
shells?
[ $xtrace = n ] || set -x
Well, they have just as much chance of being built-in as test/[ does, so
I don't think this improves the odds much. If
On Wed, 2008-05-07 at 00:36 +0200, Cristian Ionescu-Idbohrn wrote:
xtrace=$(set -o | sed -rne 's/xtrace[[:space:]]+([^[:space:]]+)/\1/p')
[ $xtrace = off ] || set +x
eval $2 t_actual 21 || {
echo $1: FAIL (eval)
}
[ $xtrace = off ] || set -x
This seems
On Sat, 2008-05-03 at 01:20 +0200, Denys Vlasenko wrote:
echo FOO | { thing being tested; read foo; }; echo $foo
If $foo is not set to FOO, thing ate FOO. Bad thing, bad.
This won't work in most POSIX shells. In most shells, every part of a
pipeline is invoked in a subshell, which means $foo
On Fri, 2008-05-02 at 19:27 -0400, Paul Smith wrote:
Plus, if the thing DID eat FOO, then the read will never return and
your test will hang.
Oops, that was stupid. Of course that's not right. The first point
stands though.
You can rewrite it like this and I think it will work
On Fri, 2008-05-02 at 19:29 -0400, Paul Smith wrote:
echo FOO | { some command; read foo; echo $foo; }
If that prints FOO you're OK; otherwise some command used it up.
Sorry for all the mail.
The big problem with this is you lose the exit code for some command.
Maybe this instead
On Mon, 2008-04-28 at 10:22 -0400, Paul Fox wrote:
Completely agree! -n clearly means a non-empty string. Without the -n
or
-z, are we interested in the variable's string or numerical vaue?
the string. that's how it's defined, and always has been.
Not that it matters, but I've been
On Fri, 2008-04-25 at 21:24 +0200, Denys Vlasenko wrote:
On Friday 25 April 2008 21:13, Cristian Ionescu-Idbohrn wrote:
Please consider the attached patch, which eliminates the use of
'basename' and 'dirname'.
Just a note: although ash does support it, local is not a POSIX shell
feature and
On Thu, 2008-04-24 at 21:09 +0200, Cristian Ionescu-Idbohrn wrote:
[ -n $bindir ] || bindir=$(dirname $(pwd))
Even better is to avoid dirname altogether. It's actually not necessary
at all in a POSIX shell; neither is basename.
The above can be rewritten much more efficiently as:
On Thu, 2008-04-24 at 23:30 +0200, Bernhard Fischer wrote:
If it is then it should be fixed to work with about the minimal shell
we provide (for self-tests and for consistency).
I agree but from the look of things it would be a bunch of work. Just
in the patches I've seen posted here there are
On Thu, 2008-04-24 at 16:30 -0400, Paul Fox wrote:
and if so, one could use $PWD.
True, but note that in the face of symlinks $PWD might not be the same
thing as the results of running pwd (the program, not the shell
builtin). That doesn't mean it's not right... but it might not be.
On Wed, 2008-04-16 at 17:59 +0200, Cristian Ionescu-Idbohrn wrote:
Please consider the 1st attachment as a POC, and then the 2nd attachment,
which is more dearer to me ;-)
???
+#define FIVETWELVE 512
How is using FIVETWELVE any better than 512? It doesn't provide ANY
abstraction at all.
On Tue, 2008-04-15 at 23:00 +0200, Denys Vlasenko wrote:
Well, we are trying to emulate bash here, and so far it does not fully
work:
I don't think we should be trying to emulate bash in this case. This
feature (#) is a POSIX standard feature, not a bash-ism, and it should
be supported by ash
On Mon, 2008-03-24 at 16:51 +, James Simmons wrote:
I have no problem with a NON_POSIX_EXTENSIONS. Is this true with the
other patches I posted?
Well, maybe we should wait for a ruling by Denys or someone. I'd really
love to have a POSIX-standard shell in busybox, and I had this idea that
On Mon, 2008-03-24 at 22:56 +0100, Denys Vlasenko wrote:
Well, maybe we should wait for a ruling by Denys or someone. I'd really
love to have a POSIX-standard shell in busybox, and I had this idea that
that was a design goal of ash.
From the practical point-of-view, bbox need
On Tue, 2008-03-25 at 01:25 +0100, Denys Vlasenko wrote:
What is the difference between test/[ and [[?
I mentioned this in an earlier email, but in case it got lost: [[ is
guaranteed to be a shell builtin and as such, it has some semantics
which make it a bit easier to use than test/[, which
How do I set the PIPESTATUS shell variable, in the ash shell?
You can't. First, PIPESTATUS is a bash extension, and is not
available in POSIX shells (which ash is trying to be).
Second, you can't have PIPESTATUS unless you also have shell
array variables, which are ALSO bash extensions and not
On Mon, 2007-07-09 at 14:22 -0500, Dallas Clement wrote:
Can somebody tell me what the difference is between these two commands?
I'm assuming both should work with a .deb package...
The man page sez:
dpkg-deb packs, unpacks and provides information about Debian
archives.
On Thu, 2007-07-05 at 10:38 -0600, Jim Freeman wrote:
There is a discrepency (== error?) in ash's handling of the following:
# [ ! a = b ]
# echo $?
1
According to the POSIX standard, this form is valid and ash's answer is
wrong.
If I'm doing something stupid, let me know - I can take it
On Wed, 2007-06-27 at 05:02 -0500, Dallas Clement wrote:
Can anyone please suggest a reference to some good Ash scripting
documentation? I am trying to implement scripting like I'm using
Bourne shell and things are not behaving too well...
Most likely you're actually using bash syntax, not
On Wed, 2007-06-27 at 05:18 -0500, Dallas Clement wrote:
if [ main ]; then
This doesn't call the function main. It sends the string main to
the test program to see if it's true, which it is.
You want:
if main; then
Note that output from scripts run at init time may well not go where
On Wed, 2007-06-27 at 17:08 +0200, Alexander Kriegisch wrote:
I do not have a dedicated ash reference either, but as I am working on
a firmware mod for a WLAN/DSL router series called Fritz!Box by AVM
and always use ash, I can encourage you to refer to man sh on any
Linux desktop. This is not
On Wed, 2007-06-27 at 17:38 +0200, Alexander Kriegisch wrote:
I was ignorant of the Open Group source which I will look into myself.
thanks for this link.
Note they also have a FireFox search engine available that you can
install; then you just select that engine and type your function or
On Wed, 2007-06-27 at 11:48 -0400, Paul Fox wrote:
for quite some time, ash was virtually identical to debian's
dash, except for source layout, and busybox config mods.
as i understood it (though i may be wrong on this point), dash
is what is now used as ubuntu's /bin/sh. if this is the
60 matches
Mail list logo
