RE: ash: "source " makes ash exit?
"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 15, 2013 5:02 PM To: Mike Frysinger Cc: busybox@busybox.net Subject: Re: ash: "source " makes ash exit? Hi Mike ! >"source" is not in POSIX and thus is not technically portable. Not in POSIX? Wow, who removed this? Even old AT&T systems did understand the "source". ... and just a hint about technically portable: alias source=. ... and even dash shall understand "source" -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash: "source " makes ash exit?
Hi Mike ! >"source" is not in POSIX and thus is not technically portable. Not in POSIX? Wow, who removed this? Even old AT&T systems did understand the "source". ... and just a hint about technically portable: alias source=. ... and even dash shall understand "source" -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash: "source " makes ash exit?
Hi, On Sat, Mar 16, 2013 at 12:38:28AM +0100, Harald Becker wrote: > >"source" is bashism, and "." should be preferred for portability. > > Definitely not! Even very old Unix shells (and alike) back in the 80th > accepted both syntax forms (but shells are different and not all are > standards conform). I do not know, what the standards documents tell > about this, I prefere "source" in scripts (sh not bash) for it's better > readability (and it's easier to search). I used to think so too, but e.g. when Debian changed /bin/sh to dash, many of my scripts broke badly. So it's good to check the standards documents every once in a while... A. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash: "source " makes ash exit?
On Friday 15 March 2013 19:38:28 Harald Becker wrote: > >"source" is bashism, and "." should be preferred for portability. > > Definitely not! Even very old Unix shells (and alike) back in the 80th > accepted both syntax forms (but shells are different and not all are > standards conform). I do not know, what the standards documents tell > about this, I prefere "source" in scripts (sh not bash) for it's better > readability (and it's easier to search). "source" is not in POSIX and thus is not technically portable. dash for one does not support it. -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash: "source " makes ash exit?
Hi Aaro ! >"source" is bashism, and "." should be preferred for portability. Definitely not! Even very old Unix shells (and alike) back in the 80th accepted both syntax forms (but shells are different and not all are standards conform). I do not know, what the standards documents tell about this, I prefere "source" in scripts (sh not bash) for it's better readability (and it's easier to search). -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash: "source " makes ash exit?
Hi, On Sat, Mar 16, 2013 at 12:04:12AM +0100, Harald Becker wrote: > Hi Matthew ! > >I've heard rumors that backticks are discouraged in favor of $( )... > >Can we do the same for . in favor of source? You can't exactly grep > >for '.' > > It was just a hint for novices that both syntax forms behave identical > and description may be used for both. There was no preference which > form shall be used, otherwise you are right. I prefer $() and source > within scripts and tend to use backticks and dot on command line. "source" is bashism, and "." should be preferred for portability. A. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash: "source " makes ash exit?
Hi Matthew ! >> [ -f SCRIPTFILE ] && source SCRIPTFILE || error action >> (also -r instead of -f may be used) > >-r is preferable because then your script won't fail if the file is >unreadable Depends on usage. If the script runs as user root (e.g. as linuxrc on initramfs), every file/device is readable, so you are more likely interested to test if it is a regular file (think of source /dev/zero). If you run scripts as normal user, the readable test may be preferable ... or you tend to use both tests: [ -f SCRIPTFILE -a -r SCRIPTFILE ] && ... will only succeed if it's a readable regular file :) ... but depending on usage this extra text could be overdone (make things slower). >> [For the novice: ". SCRIPTFILE" is same as "source SCRIPTFILE"; just >> an alias syntax] > >I've heard rumors that backticks are discouraged in favor of $( )... >Can we do the same for . in favor of source? You can't exactly grep >for '.' It was just a hint for novices that both syntax forms behave identical and description may be used for both. There was no preference which form shall be used, otherwise you are right. I prefer $() and source within scripts and tend to use backticks and dot on command line. -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash: "source " makes ash exit?
On Friday 15 March 2013 17:14:09 Bastian Bittorf wrote: > also: i could'nt find any documentation how > it _should_ be handled. if you want to know how a POSIX shell should behave, look at the POSIX spec: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html if you want to know how bash extensions should behave, read bash's man page or try running it. these are really the only two things that matter to busybox. -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash: "source " makes ash exit?
On Friday 15 March 2013 16:54:24 Joshua Judson Rosen wrote: > I just noticed that trying to source a nonexistent file from a script > running (non-interactively) through ash causes the shell to exit. > > Debian's "dash" shell doesn't do this, and versions of bash before 4.2 > apparently don't do this even when invoked with "--posix" (it looks like > bash's posix mode was always *supposed to* exit when trying to source > non-existent files, but was perhaps broken; bash's *default mode* doesn't > exit when an attempt is to source a nonexistent file, though). > > Looking at the code in busybox, it looks like there's an obvious patch that > I can make (cf. attached) in order to change this behaviour; does this > change make sense upstream? If I do it, should I predicate it on > ENABLE_ASH_COMPAT, or should I just do it unconditionally (I notice that > busybox's find_dot_file() always searches in the current directory, which > looks like a bashism)? > > Or should I just not do it, and make my shell scripts smarter? > It's not entirely clear, looking at dotcmd(), whether the INPUT_NOFILE_OK > flag/logic is intentionally omitted from the setinputfile() call, or > whether it's an oversight. aborting is correct behavior: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#dot "If no readable file is found, a non-interactive shell shall abort" this is why bash (when run in posix mode) aborts. that said, adding the behavior behind ENABLE_ASH_BASH_COMPAT should be fine -mike signature.asc Description: This is a digitally signed message part. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash: "source " makes ash exit?
> [ -f SCRIPTFILE ] && source SCRIPTFILE || error action > > (also -r instead of -f may be used) -r is preferable because then your script won't fail if the file is unreadable > [For the novice: ". SCRIPTFILE" is same as "source SCRIPTFILE"; just > an alias syntax] I've heard rumors that backticks are discouraged in favor of $( )... Can we do the same for . in favor of source? You can't exactly grep for '.' ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash: "source " makes ash exit?
Hi ! >. nonexistent_file > >is not possible, the script just stops. >there is no trap, which can handle this. >only workaround is to check existence. > >also: i could'nt find any documentation how >it _should_ be handled. the common way of > >. nonexistent_file 2>/dev/null || action > >is not possible. Have you ever seen the following line in shell scripts? [ -f SCRIPTFILE ] && source SCRIPTFILE || error action (also -r instead of -f may be used) Now ask why it's done this way? -f tests if the file is there and it is a regular file -r tests if there is a readable file or device (checks users permissions) so the simple test allows to detect missing script files and react on this. Or use an IF construct: if [ -f SCRIPTFILE ] then source SCRIPTFILE || script returned not zero else script file is missing fi This is a known issue in Unix shell programming. Several shells exit or fail if you try to source an unavailable (or unreadable) file. So you need to test before doing the source command. [For the novice: ". SCRIPTFILE" is same as "source SCRIPTFILE"; just an alias syntax] -- Harald ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: ash: "source " makes ash exit?
* Joshua Judson Rosen [15.03.2013 22:00]: > I just noticed that trying to source a nonexistent file from a script running > (non-interactively) through ash causes the shell to exit. i also stumpled over the same? problem. . nonexistent_file is not possible, the script just stops. there is no trap, which can handle this. only workaround is to check existence. also: i could'nt find any documentation how it _should_ be handled. the common way of . nonexistent_file 2>/dev/null || action is not possible. bye, bastian ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
ash: "source " makes ash exit?
I just noticed that trying to source a nonexistent file from a script running
(non-interactively) through ash causes the shell to exit.
Debian's "dash" shell doesn't do this, and versions of bash before 4.2
apparently don't do this even when invoked with "--posix" (it looks like bash's
posix mode was always *supposed to* exit when trying to source non-existent
files, but was perhaps broken; bash's *default mode* doesn't exit when an
attempt is to source a nonexistent file, though).
Looking at the code in busybox, it looks like there's an obvious patch that I
can make (cf. attached) in order to change this behaviour; does this change
make sense upstream? If I do it, should I predicate it on ENABLE_ASH_COMPAT,
or should I just do it unconditionally (I notice that busybox's find_dot_file()
always searches in the current directory, which looks like a bashism)?
Or should I just not do it, and make my shell scripts smarter?
It's not entirely clear, looking at dotcmd(), whether the INPUT_NOFILE_OK
flag/logic is intentionally omitted from the setinputfile() call, or whether
it's an oversight.
--
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr."
diff --git a/shell/ash.c b/shell/ash.c
index fbbdb06..3a629e0 100644
--- a/shell/ash.c
+++ b/shell/ash.c
@@ -12246,6 +12246,7 @@ dotcmd(int argc, char **argv)
char *fullname;
struct strlist *sp;
volatile struct shparam saveparam;
+ int inputfd;
for (sp = cmdenviron; sp; sp = sp->next)
setvareq(ckstrdup(sp->text), VSTRFIXED | VTEXTFIXED);
@@ -12269,7 +12270,11 @@ dotcmd(int argc, char **argv)
shellparam.p = argv;
};
- setinputfile(fullname, INPUT_PUSH_FILE);
+ inputfd = setinputfile(fullname, INPUT_PUSH_FILE | INPUT_NOFILE_OK);
+ if (inputfd < 0) {
+ return inputfd;
+ }
+
commandname = fullname;
cmdloop(0);
popfile();
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH 1/2 v2] ash: move code to allow setting $HOME in /etc/profile
>> move HISTFILE=$HOME/.ash_history below reading /etc/profile, >> so that /etc/profile can set $HOME. HOME can be unset when >> directly invoking ash --login from init without going through >> getty. > > Does hush also suffer from this? > No, it already reads /etc/profile before setting HISTFILE. But it doesn't read $HOME/.profile at all, should I send a patch to bring it in line with ash and other shells? Regards, Stefan Hellermann ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [git commit] hostid: do not output sign-extended host id. Closes 6056
Denys Vlasenko wrote:
On Wednesday 06 March 2013 08:27, Thierry Reding wrote:
On Mon, Mar 04, 2013 at 03:04:38AM +0100, Denys Vlasenko wrote:
commit:
http://git.busybox.net/busybox/commit/?id=9bbf6b98c42a212b8a4b1aa02975ac18bb612922
branch: http://git.busybox.net/busybox/commit/?id=refs/heads/master
Signed-off-by: Denys Vlasenko
---
coreutils/hostid.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/coreutils/hostid.c b/coreutils/hostid.c
index 5c1a4e0..e5b1f51 100644
--- a/coreutils/hostid.c
+++ b/coreutils/hostid.c
@@ -36,7 +36,8 @@ int hostid_main(int argc UNUSED_PARAM, char **argv
UNUSED_PARAM)
bb_show_usage();
}
- printf("%08lx\n", gethostid());
+ /* POSIX says gethostid returns a "32-bit identifier" */
+ printf("%08x\n", (unsigned)(uint32_t)gethostid());
That's a bit over the top. uint32_t is already unsigned.
But unsigned may one day be wider than 32 bits,
therefore, formally, if you want to print uint32_t using %d,
%u or %x, you need to widen it.
Actually, you could pass unsigned char to printf and the compiler would
widen it automatically.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: Help Please - nanddump goes on forever
Hi Steven,
On Thu, Mar 14, 2013 at 07:55:30PM -0700, Steven Hickel wrote:
> Hi, I'm new to this list and to such lists in general, so I apologize
> if I break decorum in some way. I have a specific situation I'm hoping
> someone can shed some light on. I'm making a nanddump of the userdata
> partition on a nexus one with the below commands using two Cygwin
> terminals. But, when I do this, the nanddump seems to go on forever. I
> ended up stopping it at over 8 GB written. I believe the entire
> internal storage is only something like 512 MB. The form of the below
> commands seemed to work for creating nanddumps of the other phone
> partitions. But, it's the userdata partition I'm really looking to get
> so as to potentially recover some important deleted files. Also, note
> that I have removed the external sd card so that there's no
> possibility I'm copying from that.
>
> Cygwin Terminal 1
> ---
> adb forward tcp: tcp:
> adb shell
> su
> # nanddump [options] /dev/mtd/mtd5 | nc -l -p
> ---
>
>
> Cygwin terminal 2
> -
>
> nc 127.0.0.1 > /nexus/mtd5_userdata.img
> --
>
> This approach is similar to this, but with nanddump instead of dd:
> http://forum.xda-developers.com/showthread.php?t=1994705
>
> In case it's of use, the proc/mtd file shows the following
>
> mtd0: 000e 0002 "misc"
> mtd1: 0040 0002 "recovery"
> mtd2: 0038 0002 "boot"
> mtd3: 0910 0002 "system"
> mtd4: 05f0 0002 "cache"
> mtd5: 0c44 0002 "userdata"
>
> Also, the df command in adb shell, brings up the following:
>
> Filesystem Size Used Free Blksize
> /dev192M32K 192M 4096
> /mnt/asec 192M 0K192M 4096
> /mnt/obb 192M 0K192M 4096
> /system 145M131M13M4096
> /data 196M80M 116M 4096
> /cache 95M 1M 93M 4096
>
> I hope someone can help, so I can get this image and be able to start
> using the phone again. Thank you.
Have you tried running nanddump alone, something like
nanddump /dev/mtd/mtd5 > /dev/null
Also, having the output of strace on nanddump run might give us a clue.
If you can rebuild busybox for your platform please try doing so with the
patch below applied, and post its output.
diff --git a/miscutils/nandwrite.c b/miscutils/nandwrite.c
index e3f9b56..0d69e4e 100644
--- a/miscutils/nandwrite.c
+++ b/miscutils/nandwrite.c
@@ -138,6 +138,8 @@ int nandwrite_main(int argc UNUSED_PARAM, char **argv)
if (length < meminfo.size - mtdoffset)
end_addr = mtdoffset + length;
}
+ fprintf(stderr, "%s: size: %x end_addr: %x\n", __func__, meminfo.size,
+ end_addr);
/* Pull it into a CPU register (hopefully) - smaller code that way */
meminfo_writesize = meminfo.writesize;
@@ -176,6 +178,7 @@ int nandwrite_main(int argc UNUSED_PARAM, char **argv)
int input_fd = IS_NANDWRITE ? STDIN_FILENO : fd;
int output_fd = IS_NANDWRITE ? fd : STDOUT_FILENO;
+ fprintf(stderr, "%s: mtdoffset %x\n", __func__, mtdoffset);
blockstart = mtdoffset & ~(meminfo.erasesize - 1);
if (blockstart == mtdoffset) {
/* starting a new eraseblock */
--
http://baruch.siach.name/blog/ ~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
