Re: No brace expansion for ash?
If other systems think Linux is irrelevant, Linux crowd can easily take the same stance and declare all other (unix) systems irrelevant. I leave it up to you to guess who is going to win such battle. I don't know who's going to win, but I know for sure who's going to lose: the users. I don't care whether hush or ash supports brace expansion or not. I have stopped using the shell as a script language altogether anyway, and am using execline instead (and other people working in embedded environments should definitely consider it too). What I do care about, though, is compatibility from one Unix platform to another, and calling a spade a spade. 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 growing dozens of platform-specific extensions. Bashisms are arguably Linux-specific extensions to Single Unix, don't you think ? ;) If hush is supposed to emulate bash, the GNU shell rather than sh, the POSIX shell, then it's fine, no problem, but it needs to be clearly documented as such. In any case, a FAQ entry such as Why are there two shells implementations in BusyBox? or What are the differences between ash and hush? would help, and avoid such arguments in the future. I would gladly write such an entry myself if I knew more about the internal workings of ash and hush. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: No brace expansion for ash?
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 growing dozens of platform-specific extensions. Bashisms are arguably Linux-specific extensions to Single Unix, don't you think ? ;) no, not even close. i dont know why people think bash == Linux, but it doesnt. it is actively used on many many more systems than just Linux, and i guess i need to point out the fact that bash is far older than Linux. -mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: No brace expansion for ash?
On Mon, Jul 11, 2011 at 02:23, 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 growing dozens of platform-specific extensions. Bashisms are arguably Linux-specific extensions to Single Unix, don't you think ? ;) no, not even close. i dont know why people think bash == Linux, but it doesnt. it is actively used on many many more systems than just Linux, and i guess i need to point out the fact that bash is far older than Linux. along these lines, i'm pretty sure the bash maintainer runs OS X as his main desktop / development system. when people report bugs, he often shows how it's working for him under OS X. that's decidedly un-Linux-y. -mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: No brace expansion for ash?
Bashisms are arguably Linux-specific extensions to Single Unix, don't you think ? ;) no, not even close. i dont know why people think bash == Linux, but it doesnt. it is actively used on many many more systems than just Linux, and i guess i need to point out the fact that bash is far older than Linux. Okay, then replace Linux-specific with GNU-specific; as far as I know, GNU is still not Unix, *especially in embedded environments that BusyBox is targetting*, and bash is still not the reference sh implementation. But you have a point. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: No brace expansion for ash?
On 11 Jul 2011 at 8:47, Laurent Bercot wrote: Date sent: Mon, 11 Jul 2011 08:47:10 +0200 From: Laurent Bercot ska-dietl...@skarnet.org To: busybox@busybox.net Subject:Re: No brace expansion for ash? Bashisms are arguably Linux-specific extensions to Single Unix, don't you think ? ;) no, not even close. i dont know why people think bash == Linux, but it doesnt. it is actively used on many many more systems than just Linux, and i guess i need to point out the fact that bash is far older than Linux. Okay, then replace Linux-specific with GNU-specific; as far as I know, GNU is still not Unix, *especially in embedded environments that BusyBox is targetting*, and bash is still not the reference sh implementation. But you have a point. -- Laurent As an user, I've got concerns with how scripts work in shells. I've used checkbashism to try and elimanate them, but don't know if it finds all of them. I've even run into an issue where bash worked with a for loop, but after upgrading to a newer version it no longer worked. I've got a project that I took over way back in 2004, and it used busybox for most things, but did included the full bash to run scripts? It might work with a busybox shell, but going thru a 2000+ line script to check for any issues has prompted me to just leave the 877480 byte bash as part of the iso image. Is there a program that can fully check scripts for bashisms or other problems. Thanks for the great work on the busybox project... ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox +--+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mi...@kuentos.guam.net mailto:msetze...@gmail.com http://www.guam.net/home/mikes Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +--+ http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489) BOINC@HOME CREDITS SETI10984133.148723 | EINSTEIN 6161606.870851 ROSETTA 3358525.001787 | ABC 6810712.402492 ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: No brace expansion for ash?
On 11 July 2011 08:08, Michael D. Setzer II mi...@kuentos.guam.net wrote: On 11 Jul 2011 at 8:47, Laurent Bercot wrote: Bashisms are arguably Linux-specific extensions to Single Unix, don't you think ? ;) no, not even close. i dont know why people think bash == Linux, but it doesnt. it is actively used on many many more systems than just Linux, and i guess i need to point out the fact that bash is far older than Linux. Okay, then replace Linux-specific with GNU-specific; as far as I know, GNU is still not Unix, *especially in embedded environments that BusyBox is targetting*, and bash is still not the reference sh implementation. But you have a point. -- Laurent As an user, I've got concerns with how scripts work in shells. I've used checkbashism to try and elimanate them, but don't know if it finds all of them. I've even run into an issue where bash worked with a for loop, but after upgrading to a newer version it no longer worked. I've got a project that I took over way back in 2004, and it used busybox for most things, but did included the full bash to run scripts? It might work with a busybox shell, but going thru a 2000+ line script to check for any issues has prompted me to just leave the 877480 byte bash as part of the iso image. Is there a program that can fully check scripts for bashisms or other problems. I don't see how adding bashisms one-by-one to ash is going to help anyone. If you want to run a script under ash, you should write it properly and test it under ash -- which should be faithful enough to the sh spec not to tolerate bashisms. If you have a script that is full of bashisms, the solution is to run it under the intended interpreter: bash. Chris ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: No brace expansion for ash?
People that do embedded generally have other concerns like porting porting a bootloader for the board they are using. Mending some scripts so that they work with the shell they chose to use with busybox is not really a concern Da: Chris Rees utis...@gmail.com Oggetto: Re: No brace expansion for ash? A: Michael D. Setzer II mi...@kuentos.guam.net Cc: busybox@busybox.net Data: Lunedì 11 luglio 2011, 10:16 On 11 July 2011 08:08, Michael D. Setzer II mi...@kuentos.guam.net wrote: On 11 Jul 2011 at 8:47, Laurent Bercot wrote: Bashisms are arguably Linux-specific extensions to Single Unix, don't you think ? ;) no, not even close. i dont know why people think bash == Linux, but it doesnt. it is actively used on many many more systems than just Linux, and i guess i need to point out the fact that bash is far older than Linux. Okay, then replace Linux-specific with GNU-specific; as far as I know, GNU is still not Unix, *especially in embedded environments that BusyBox is targetting*, and bash is still not the reference sh implementation. But you have a point. -- Laurent As an user, I've got concerns with how scripts work in shells. I've used checkbashism to try and elimanate them, but don't know if it finds all of them. I've even run into an issue where bash worked with a for loop, but after upgrading to a newer version it no longer worked. I've got a project that I took over way back in 2004, and it used busybox for most things, but did included the full bash to run scripts? It might work with a busybox shell, but going thru a 2000+ line script to check for any issues has prompted me to just leave the 877480 byte bash as part of the iso image. Is there a program that can fully check scripts for bashisms or other problems. I don't see how adding bashisms one-by-one to ash is going to help anyone. If you want to run a script under ash, you should write it properly and test it under ash -- which should be faithful enough to the sh spec not to tolerate bashisms. If you have a script that is full of bashisms, the solution is to run it under the intended interpreter: bash. Chris ___ 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: No brace expansion for ash?
Denys, I'd like to start by assuring you that I have a great amount of respect for the work you put in to a highly important piece of software, and would like to thank you for your positive responses in helping to improve its portability. On 11 July 2011 01:50, Denys Vlasenko vda.li...@googlemail.com wrote: On Sunday 10 July 2011 21:02, Chris Rees wrote: Of course it's up to the Busybox project to set your own policy -- my problem with adding non-standard features to shells is that people rely on them and write incompatible scripts when *all that is needed* is to just use the correct language in the first place. Bash was used in Linux from the very beginning, which makes it a de-facto standard. It doesn't matter whether you or me like it or not, we must account for the fact that long-time Linux users are used to it. Forcing them to stop using all bashisms is both counter-productive and arrogant. I find it unfair for you to call me arrogant when you are asserting that everyone else should bow to Linux pressure and allow nonstandard 'extensions'. What about the large numbers of people who struggle with breakage because of the 'arrogant' people who write bash scripts and put it into autoconf scripts? Or, worse assume that [ $1 == $2 ] is valid [1]? Or using find with no directory arguments? I don't think it's too much of a straw man to compare this with expecting C to support foreach, or expecting the 'dir' command to work (like RH7 did...). The difference is that C never supported foreach. Shell in Linux did support brace expansion. More important example: Shell in Linux always had echo builtin not interpreting backslash escapes, and acception -n and -e options. The approach dash took when they broke echo builtin compatibility (!) in several ways at once (!!) angered a lot of people. Do dash developers really think that they did more for Linux than bash, and thus have a moral right to cause breakage to millions of users? The breakage is the fault of people writing scripts that assume that /bin/sh is bash -- who in turn are being encouraged by distributions that link them. Also, the dash developers take a lot of the credit for speeding up boot of Debian-based systems; stripping out the extensions makes startup of a scripting shell much quicker. However, I can see that this avenue of reason is not going to change any minds, so I'm going to apologise for jumping on Eric like that and advising against the patch -- it wasn't really my place to say that and I accept that. Can I make a final plea, if this is implemented as an option, can it please be disabled by default? This should make people more aware that it's a nonstandard function -- bash may be the standard shell on GNU systems, but it's not in most other OSes. If other systems think Linux is irrelevant, Linux crowd can easily take the same stance and declare all other (unix) systems irrelevant. I leave it up to you to guess who is going to win such battle. I have not once said that Linux is irrelevant, I am just saying that there is no need to (partly!) reimplement bash when there's a much easier and more practical way to do it. Chris [1] On FreeBSD at least, this has been 'fixed'. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: No brace expansion for ash?
if *you* want a minimal POSIX compliant shell out of busybox with no bash features, you can already do that today. but *your* needs are not the same as everyone else's Please stop misunderstanding my needs and misrepresenting my position (voluntarily or not), and read my first message again. I am not opposed to the additions of bashisms to hush, or even ash for that matter. All I am saying is that if hush's objective is to emulate bash and not sh, *this should be made abundantly clear and documented*. People should know exactly what they are getting when they build hush. -- Laurent ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: segmentation fault
On 07/10/2011 09:53 AM, walter harms wrote: Am 09.07.2011 19:50, schrieb David Henderson: Gang, I've added some new kernel modules to the file system so I tried to update the modules.dep file using depmod, but I get a segmentation fault when trying to execute it. I even tried using the '-ae' parameters (although they aren't listed in the help for the applet). Any thoughts on how to fix this? I'm running BB 1.81.1. can you provide the full cmd-line you use ? you can also try to build with debug options and use gdb to locate the seqfault. re, wh Thanks for the help Walter, but I ended up finding the problem using strace. I appreciate it though! Dave ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: segmentation fault
On 07/11/2011 10:02 AM, Gilles Espinasse wrote: Selon David Hendersondhender...@digital-pipe.com: On 07/10/2011 05:29 AM, Gilles Espinasse wrote: - Original Message - From: David Hendersondhender...@digital-pipe.com To: BusyBox Developer Listbusybox@busybox.net Sent: Saturday, July 09, 2011 7:50 PM Subject: segmentation fault Gang, I've added some new kernel modules to the file system so I tried to update the modules.dep file using depmod, but I get a segmentation fault when trying to execute it. I even tried using the '-ae' parameters (although they aren't listed in the help for the applet). Any thoughts on how to fix this? I'm running BB 1.81.1. Wow BB-1.81! Anyway, you may try with strace to see where the segfault happen. And which config option is selected for modprobe? Gilles Hey Gilles, thanks for the help. Yeah I'm working with the most advanced version of busybox, 1.81 lol! Good tip using strace - I ended up tracing it to a couple of invalid symlinks and have resolved the problem. Thanks a million! Dave Probably usefull to report where the invalid symlinks were incorrectly handled? modprobe may report something like 'find not found' earlier instead of blindly segfaulting. Gilles Unfortunately I've already closed the terminal containing the strace output. I suppose I can replace one of the files with an invalid symlink and re-run depmod if you need me to. Let me know. Dave ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: No brace expansion for ash?
On Mon, Jul 11, 2011 at 04:48, Laurent Bercot wrote: if *you* want a minimal POSIX compliant shell out of busybox with no bash features, you can already do that today. but *your* needs are not the same as everyone else's Please stop misunderstanding my needs and misrepresenting my position (voluntarily or not), and read my first message again. I am not opposed to the additions of bashisms to hush, or even ash for that matter. All I am saying is that if hush's objective is to emulate bash and not sh hush's objective is to be small useful. minimum functionality available is POSIX, but adding bash extensions is generally fine. *this should be made abundantly clear and documented*. People should know exactly what they are getting when they build hush. i'm guessing you've never actually built hush. it is pretty damn clear what features you get as you have to select them one-by-one in the config system. -mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: No brace expansion for ash?
On Mon, Jul 11, 2011 at 00:56, Mike Frysinger wrote:
On Sunday, July 10, 2011 21:03:54 Rich Felker wrote:
On Sun, Jul 10, 2011 at 06:23:55PM +0100, Chris Rees wrote:
So... do we need a separate ash and hush if ash doesn't need to be
sh-compatible? I don't want to start a flamewar, but I think that
portability is very important, and adding strange extensions means
that people use code that breaks on other platforms, as you well know
from the latest patches to gen_build.sh.
Can we still call it ash if it doesn't behave like ash?
Also, what about scripts that don't expect { to be a special
character, what happens then?
This is why there's set -B. The defautl in bash is to enable brace
expansion for interactive shells (where standards supposedly don't
matter) and disable it for non-interactive ones (e.g. running
scripts). But you can override it either way with set -B or set +B.
in addition to that, the braces only get expanded if the usage warrants it.
so if the braces are quoted, or dont follow the simple syntax, the braces get
passed through like any other char.
$ echo {0..10
{0..10
$ echo '{0..10}'
{0..10}
i doubt many scripts will hit this
sorry, i realized this isnt quite what we're talking about. but the
example still holds:
$ echo abc{d,e,f,g
abc{d,e,f,g
$ echo 'abc{d,e,f,g}'
abc{d,e,f,g}
also worth noting that the brace is already a semi-reserved character
in POSIX itself. you get semi-subshells and functions with it. so
concern about it being reserved is kind of a red herring.
from POSIX:
$ { echo hi; }
hi
$ f() { echo hi; }; f
hi
-mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: No brace expansion for ash?
On Mon, Jul 11, 2011 at 04:16, Chris Rees wrote: I don't see how adding bashisms one-by-one to ash is going to help anyone. i guess you've never worked with actual customers doing embedded projects If you want to run a script under ash, you should write it properly and test it under ash -- which should be faithful enough to the sh spec not to tolerate bashisms. that's nice. your idealized view of the world (1) rarely happens and (2) requires extensive knowledge of the shell spec. fact is, most people dont know anything about this. they write some stuff cobbled together by what they found online and then test it on their desktop. then when it doesnt work on the board, they complain and time is wasted. If you have a script that is full of bashisms, the solution is to run it under the intended interpreter: bash. if *you* want to do that, then *you* can. but *your* opinion of the world does not get to dictate what optional code people get to add to busybox. this functionality is extremely useful to have in ash, and the trade off of using busybox+some extensions is a lot better than throwing full bash on there. -mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: No brace expansion for ash?
On Mon, Jul 11, 2011 at 11:24, Paul Smith wrote: We're talking about features that are available in scripts that begin #!/bin/sh, not features available in scripts that begin #!/bin/bash (or #!/bin/ash or #!/bin/hush). busybox's shells allow you to (at build time) optionally enable some bashisms. apparently some people think we shouldnt be offering that option. anyone trying to debate POSIX-vs-bash shell programming in general needs to go somewhere else. (i'm not saying any of this applies to you) -mike ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: No brace expansion for ash?
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 growing dozens of platform-specific extensions. Bashisms are arguably Linux-specific extensions to Single Unix, don't you think ? ;) no, not even close. i dont know why people think bash == Linux, but it doesnt. it is actively used on many many more systems than just Linux, and i guess i need to point out the fact that bash is far older than Linux. Yes, it's available on all sorts of systems, not just Linux. No, /bin/sh is not bash in all sorts of systems. Bash has been around much longer than Linux but before Linux, it was not installed as /bin/sh on any system, and even today it's not installed as /bin/sh on anything but Linux (and maybe OS X, I'm not familiar enough with it to know). We're talking about features that are available in scripts that begin #!/bin/sh, not features available in scripts that begin #!/bin/bash (or #!/bin/ash or #!/bin/hush). At least that's my understanding of the discussion. Cheers! ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
fdisk reinstate sleep
Hi, I've been chasing an intermittent problem with busybox's fdisk implementation. About one command in ten was failing on me when used with slow external USB disks on a 320MHz ARM system. The BLKRRPART ioctl was returning device busy. I traced it to a commented out sleep(2) in fdisk.c. With the sleep reinstated fdisk is reliable. I know that linux sync() is documented as not returning until the buffers have been flushed but I think something is delaying them, possibly in the USB stack. --- busybox-1.18.3/util-linux/fdisk.c-orig 2011-07-11 14:51:15.0 +0100 +++ busybox-1.18.3/util-linux/fdisk.c 2011-07-11 14:51:52.0 +0100 @@ -2564,7 +2564,7 @@ printf(Calling ioctl() to re-read partition table\n); sync(); - /* sleep(2); Huh? */ + sleep(2); i = ioctl_or_perror(dev_fd, BLKRRPART, NULL, WARNING: rereading partition table failed, kernel still uses old table); -- Bob Dunlop ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] Readline's mimic for reverse history search
It used to apply clean at the time of submission (based on the latest git commit). Denys, i appreciate your reviews and comments, but i think i will pull over at this point and say it works for me and i'm happy with that. If someone is interested, he can take it from here. Though i don't see that someone is too much interested in this patch. Especially seeing the brace expansion in ash thread. Thank you and take care! On Mon, 11 Jul 2011, Denys Vlasenko wrote: On Monday 04 July 2011 09:10, kyak wrote: Implemented readline's mimic for reverse history search (Ctrl+r). Reworked based on Denys Vlasenko remarks. patch -p1 /tmp/z.diff patching file libbb/Config.src Hunk #1 FAILED at 94. 1 out of 1 hunk FAILED -- saving rejects to file libbb/Config.src.rej patching file libbb/lineedit.c Hunk #1 FAILED at 1948. Hunk #2 FAILED at 2381. 2 out of 2 hunks FAILED -- saving rejects to file libbb/lineedit.c.rej + /* matched lines from history are here */ + char *cmdline_buf; If you need a comment to explain the role of this variable, then you need a better name for the variable. + char *prmt_mem_ptr = xzalloc(1); ??? + /* save the real prompt */ + char *prmt_mem_ptr_save = xzalloc(1); Not only operation is pointless and leaks memory, but comment is also misplaced at best. + cmdedit_y_add_prev = 0; + cmdedit_y_add_cmp = 0; ... + cmdedit_y_add_cmp = ; + cmdedit_y_add_prev = cmdedit_y_add_cmp; Redundant assignments. + prmt_mem_ptr = xstrdup(prmt); You never free it: memory leak. + match_buf = xmalloc(MAX_LINELEN * sizeof(int16_t)); You never free it: memory leak. + cmdline_buf = xmalloc(MAX_LINELEN * sizeof(int16_t)); You never free it: memory leak. The only time you use allocated memory, namely here in case the search was unsuccessful: + len_cmd = mbstowcs(wc, cmdline_buf, sizeof(wc)); + if (len_cmd 0) + len_cmd = strlen(cmdline_buf); you use uninitialized data. +#if ENABLE_UNICODE_SUPPORT + /* convert to wide char string, +* delete char, then convert back */ + len = mbstowcs(wc, match_buf, sizeof(wc)); + if (len 0) + len = 0; + wc[len-1] = '\0'; + wcstombs(match_buf, wc, MAX_LINELEN); +#else + match_buf[strlen(match_buf)-1] = '\0'; +#endif What will happen if match_buf is empty string? And so on... -- vda ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
RE: No brace expansion for ash?
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 http://lists.busybox.net/mailman/listinfo/busybox
[PATCH] ash: add support for history buffer
Ash writes to ~/.ash_history after every command, causing excessive
wear on devices which use a flash-based device as their storage medium
(i.e. one erase block cycle per command).
This patch allows you to set a temporary location where ash's history
will be saved until the shell is exited.
The patch is a bit hackish, but seems to do its job fine.
Signed-off-by: Dennis Groenen tj.groe...@gmail.com
---
shell/ash.c | 51 +++
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/shell/ash.c b/shell/ash.c
index d48cd01..940dfe9 100644
--- a/shell/ash.c
+++ b/shell/ash.c
@@ -184,6 +184,24 @@
//config:This option recreates the prompt string from the environment
//config:variable each time it is displayed.
//config:
+//config:config ASH_HIST_BUFFER
+//config: bool History buffer
+//config: default n
+//config: depends on ASH FEATURE_EDITING_SAVEHISTORY
+//config: help
+//config:Allows you to set a temporary location for .ash_history.
+//config:History is saved to this custom location, and written out to
+//config:its default location (~/.ash_history) upon shell exit.
+//config:Useful to prevent wear on flash-based storage devices.
+//config:
+//config:config ASH_HIST_BUFFER_PATH
+//config: string History buffer location
+//config: default /tmp
+//config: depends on ASH ASH_HIST_BUFFER
+//config: help
+//config:Directory which will be used to save the shell history until
+//config:ash is exited.
+//config:
//applet:IF_ASH(APPLET(ash, BB_DIR_BIN, BB_SUID_DROP))
//applet:IF_FEATURE_SH_IS_ASH(APPLET_ODDNAME(sh, ash, BB_DIR_BIN,
BB_SUID_DROP, sh))
@@ -12888,6 +12906,14 @@ exitshell(void)
char *p;
int status;
+#if ENABLE_ASH_HIST_BUFFER
+ const char *tmphistory = lookupvar(HISTFILE);
+ const char *storedhistory = lookupvar(STOREDHISTFILE);
+
+ if (access(tmphistory, R_OK) == 0)
+ copy_file(tmphistory, storedhistory, 11); /* 11 = force copy
preserve permissions */
+#endif
+
status = exitstatus;
TRACE((pid %d, exitshell(%d)\n, getpid(), status));
if (setjmp(loc.loc)) {
@@ -13151,9 +13177,34 @@ int ash_main(int argc UNUSED_PARAM, char **argv)
if (!hp) {
hp = lookupvar(HOME);
if (hp) {
+#if ENABLE_ASH_HIST_BUFFER
+ char *tmphistory;
+ char *storedhistory;
+ const char *user = lookupvar(USER);
+
+ if (access(CONFIG_ASH_HIST_BUFFER_PATH, R_OK ==
-1))
+ bb_make_directory(xasprintf(%s,
CONFIG_ASH_HIST_BUFFER_PATH),
01777, FILEUTILS_RECUR);
+
+ tmphistory =
concat_path_file(CONFIG_ASH_HIST_BUFFER_PATH,
+ xasprintf(.ash_hist_%s, user));
+ storedhistory = concat_path_file(hp,
.ash_history);
+
+ /* Create ~/.ash_history if non-existant */
+ if (access(storedhistory, R_OK) == -1)
+ close(open(storedhistory, O_WRONLY |
O_CREAT, 0644));
+ /* Copy stored history to buffer locaton if the
latter is non-existant */
+ if (access(tmphistory, R_OK | W_OK) == -1)
+ copy_file(storedhistory, tmphistory,
11); /* 11 = force copy
preserve permissions */
+
+ setvar(HISTFILE, tmphistory, 0);
+ setvar(STOREDHISTFILE, storedhistory, 0);
+ free(storedhistory);
+ free(tmphistory);
+#else
char *defhp = concat_path_file(hp,
.ash_history);
setvar(HISTFILE, defhp, 0);
free(defhp);
+#endif
}
}
}
--
1.7.6
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: add support for history buffer
From 90b148277f665a536cf4b2e1214a2e887e236556 Mon Sep 17 00:00:00 2001
From: Dennis Groenen tj.groe...@gmail.com
Date: Mon, 11 Jul 2011 17:28:19 +0200
Subject: [PATCH] ash: add support for history buffer
Signed-off-by: Dennis Groenen tj.groe...@gmail.com
---
shell/ash.c | 51 +++
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/shell/ash.c b/shell/ash.c
index d48cd01..940dfe9 100644
--- a/shell/ash.c
+++ b/shell/ash.c
@@ -184,6 +184,24 @@
//config: This option recreates the prompt string from the environment
//config: variable each time it is displayed.
//config:
+//config:config ASH_HIST_BUFFER
+//config: bool History buffer
+//config: default n
+//config: depends on ASH FEATURE_EDITING_SAVEHISTORY
+//config: help
+//config: Allows you to set a temporary location for .ash_history.
+//config: History is saved to this custom location, and written out to
+//config: its default location (~/.ash_history) upon shell exit.
+//config: Useful to prevent wear on flash-based storage devices.
+//config:
+//config:config ASH_HIST_BUFFER_PATH
+//config: string History buffer location
+//config: default /tmp
+//config: depends on ASH ASH_HIST_BUFFER
+//config: help
+//config: Directory which will be used to save the shell history until
+//config: ash is exited.
+//config:
//applet:IF_ASH(APPLET(ash, BB_DIR_BIN, BB_SUID_DROP))
//applet:IF_FEATURE_SH_IS_ASH(APPLET_ODDNAME(sh, ash, BB_DIR_BIN, BB_SUID_DROP, sh))
@@ -12888,6 +12906,14 @@ exitshell(void)
char *p;
int status;
+#if ENABLE_ASH_HIST_BUFFER
+ const char *tmphistory = lookupvar(HISTFILE);
+ const char *storedhistory = lookupvar(STOREDHISTFILE);
+
+ if (access(tmphistory, R_OK) == 0)
+ copy_file(tmphistory, storedhistory, 11); /* 11 = force copy preserve permissions */
+#endif
+
status = exitstatus;
TRACE((pid %d, exitshell(%d)\n, getpid(), status));
if (setjmp(loc.loc)) {
@@ -13151,9 +13177,34 @@ int ash_main(int argc UNUSED_PARAM, char **argv)
if (!hp) {
hp = lookupvar(HOME);
if (hp) {
+#if ENABLE_ASH_HIST_BUFFER
+char *tmphistory;
+char *storedhistory;
+const char *user = lookupvar(USER);
+
+if (access(CONFIG_ASH_HIST_BUFFER_PATH, R_OK == -1))
+ bb_make_directory(xasprintf(%s, CONFIG_ASH_HIST_BUFFER_PATH), 01777, FILEUTILS_RECUR);
+
+tmphistory = concat_path_file(CONFIG_ASH_HIST_BUFFER_PATH,
+ xasprintf(.ash_hist_%s, user));
+storedhistory = concat_path_file(hp, .ash_history);
+
+/* Create ~/.ash_history if non-existant */
+if (access(storedhistory, R_OK) == -1)
+ close(open(storedhistory, O_WRONLY | O_CREAT, 0644));
+/* Copy stored history to buffer locaton if the latter is non-existant */
+if (access(tmphistory, R_OK | W_OK) == -1)
+ copy_file(storedhistory, tmphistory, 11); /* 11 = force copy preserve permissions */
+
+setvar(HISTFILE, tmphistory, 0);
+setvar(STOREDHISTFILE, storedhistory, 0);
+free(storedhistory);
+free(tmphistory);
+#else
char *defhp = concat_path_file(hp, .ash_history);
setvar(HISTFILE, defhp, 0);
free(defhp);
+#endif
}
}
}
--
1.7.6
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
Re: No brace expansion for ash?
On Mon, Jul 11, 2011 at 05:27, Chris Rees wrote:
On 11 July 2011 09:48, Laurent Bercot wrote:
if *you* want a minimal POSIX compliant shell out of busybox with no bash
features, you can already do that today. but *your* needs are not the
same as everyone else's
Please stop misunderstanding my needs and misrepresenting my position
(voluntarily or not), and read my first message again.
I am not opposed to the additions of bashisms to hush, or even ash for
that matter.
All I am saying is that if hush's objective is to emulate bash and not
sh, *this should be made abundantly clear and documented*. People should
know exactly what they are getting when they build hush.
Really, this is what I would be happy with too. I have no problem with
bashisms in hush -- it's a 'Busybox-ism'. The problem I have is having
an ash that doesn't behave like an ash
if you dont want features in ash, then dont configure them in. if you
want portability for your scripts, then stick to POSIX.
cat EOF
#!/bin/sh
mkdir {build src bluurgh}
cd build || echo WHY ISN'T SH BASH???
EOF
guessing you meant to use cat EOF test.sh and then execute
test.sh. beyond that, i'm guessing you also meant to use commas in
the middle of that brace instead of spaces as your current code for
all shells (bash, POSIX sh, dash, ash, etc...) creates three dirs:
{build src bluurgh}
then testing them with ash, it working fine and then being surprised
when it breaks for others.
again, that's your business which has no bearing on what people choose
to do on their own systems.
-mike
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
RE: No brace expansion for ash?
We're talking about features that are available in scripts that begin #!/bin/sh, not features available in scripts that begin #!/bin/bash (or #!/bin/ash or #!/bin/hush). Just a suggestion that came to mind when reading this: Whould it not be possible to build different applets called ash, hush, bash and even sh depending on the configuration options? I am fully aware that such a bash-applet whould just be 80-90% bash, but still? It would certainly be a nice twist that solved a lot of confusion. AFAIK, currently it would not be possible to build more than one of those derivate applets (apart from ash and hush), but that is where we are today anyway. Cheers /Sven ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: No brace expansion for ash?
On Monday, July 11, 2011 17:20:31 Rich Felker wrote:
On Mon, Jul 11, 2011 at 11:19:01AM -0400, Mike Frysinger wrote:
in addition to that, the braces only get expanded if the usage warrants
it. so if the braces are quoted, or dont follow the simple syntax, the
braces get passed through like any other char.
$ echo {0..10
{0..10
$ echo '{0..10}'
{0..10}
i doubt many scripts will hit this
Irrelevant. Some will. and you break them. Bash does not break them
because brace expansion is off-by-default in non-interactive shells.
sorry, but that's incorrect. bash does brace expansion by default. only `set
+B` turns it off. the man page says this, as does simple testing.
$ readlink /bin/sh
bash
$ sh -c 'echo {a,b}'
a b
$ printf '#!/bin/sh\necho {a,b}' test.sh
$ sh ./test.sh
a b
$ chmod a+rx test.sh
$ ./test.sh
a b
also worth noting that the brace is already a semi-reserved character
in POSIX itself. you get semi-subshells and functions with it. so
concern about it being reserved is kind of a red herring.
Completely different context, also irrelevant. POSIX specifies that
echo {a,b} prints the string {a,b} not a b.
my point is that the breakage is minor and the real world impact is
insignificant at best. and, again, if *you* dont want this behavior, then
*dont enable it in your busybox config*.
-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: fdisk reinstate sleep
On Mon, Jul 11, 2011 at 2:16 PM, Rich Felker dal...@aerifal.cx wrote: I know that linux sync() is documented as not returning until the buffers have been flushed but I think something is delaying them, possibly in the USB stack. In my opinion the patch is unacceptable as-is. Any sleeps need to be optional and off-by-default, and at least someone should investigate the time actually needed. Or it could just loop retrying until it's no longer busy. This would be much more robust. The BLKRRPART ioctl can return EBUSY forever if somebody still has a partition on that disk open. Example: # sleep 1 /dev/sda1 [1] 588 # fdisk /dev/sda The number of cylinders for this disk is set to 121601. There is nothing wrong with that, but this is larger than 1024, and could in certain setups cause problems with: 1) software that runs at boot time (e.g., old versions of LILO) 2) booting and partitioning software from other OSs (e.g., DOS FDISK, OS/2 FDISK) Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table fdisk: WARNING: rereading partition table failed, kernel still uses old table: Device or resource busy # ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: No brace expansion for ash?
Why such topics are so popular, huh? Ash is ash, bash is bash. Ash is not bash. Bash is not ash. Standards are written, and are followed. Please, stop this flame war. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
Re: [PATCH] ash: add support for history buffer
Hey! history is good, at least for grepping inside it. And it's useful to have history left on re-login. History must be permanent, and removable by request. ___ busybox mailing list busybox@busybox.net http://lists.busybox.net/mailman/listinfo/busybox
