Re: ash.c history loading and ENABLE_FEATURE_EDITING_SAVEHISTORY

[Kang-Che Sung]

2017年12月24日 09:17，"Ceriel Jacobs" 寫道：

There is no need to remember what was just typed.
There is a need to use commands that were typed a long time (years) ago.


Disasters often happen a long time after the backup (script/system) was
made.


The point is that you don't have to:
1. remember the commands
2. type the commands
3. correct typing mistakes


I know that I can save .ash_history
but it seems I can't load it without feature ENABLE_FEATURE_EDITING_SAVEHISTORY
set.


And convincing Arch Linux developers to turn on the
ENABLE_FEATURE_EDITING_SAVEHISTORY feature will be difficult. Because in
their initramfs environment they don't want to have a SAVEHISTORY to file
functionality.


I'm not convinced by this. Since your use case is a very rare one
(read-only "history" somehow defeats the purpose of the history - and it
overlaps what pre-written shell function is for). While I'm not one who can
make decisions on this, I'd suggest you just keep your local patch to do
this.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: ash.c history loading and ENABLE_FEATURE_EDITING_SAVEHISTORY

[Ceriel Jacobs]

There is no need to remember what was just typed.
There is a need to use commands that were typed a long time (years) ago.


Disasters often happen a long time after the backup (script/system) was 
made.



The point is that you don't have to:
1. remember the commands
2. type the commands
3. correct typing mistakes


I know that I can save .ash_history
but it seems I can't load it without feature 
ENABLE_FEATURE_EDITING_SAVEHISTORY set.



And convincing Arch Linux developers to turn on the 
ENABLE_FEATURE_EDITING_SAVEHISTORY feature will be difficult. Because in 
their initramfs environment they don't want to have a SAVEHISTORY to 
file functionality.



On 24-12-17 at 01:10 Kang-Che Sung wrote:



2017-12-24 07:55，"Ceriel Jacobs" >寫道：


It seems that BusyBox v1.27.2 doesn't load history from a history
file when ENABLE_FEATURE_EDITING_SAVEHISTORY is not set.

I think that the corresponding source code logic is here:
>

Such logic doesn't match the feature name, which is ...SAVEHISTORY
and not ...LOADHISTORY.

For example:
Busybox is often used in (emergency/disaster) recovery environments.
There is no need for any saving (readonly media). However it comes
handy when frequently used commands can be pre-loaded into the
initramfs (for interactive logins).

Is such a loadhistory-without-savehistory scenario tackled when
changing:

#if MAX_HISTORY > 0 && ENABLE_FEATURE_EDITING_SAVEHISTORY

to

#if MAX_HISTORY > 0

in ash.c?

In case it is not, what more to change to allow loading a HISTFILE
when ENABLE_FEATURE_EDITING_SAVEHISTORY is not set?


What's the point of loading frequently used commands if you don't save 
what you have typed *just now*? You can have .ash_history in a temp 
filesystem if you like, but it still counts as saving the history.



___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: ash.c history loading and ENABLE_FEATURE_EDITING_SAVEHISTORY

[Kang-Che Sung]

2017-12-24 07:55，"Ceriel Jacobs" 寫道：

It seems that BusyBox v1.27.2 doesn't load history from a history file when
ENABLE_FEATURE_EDITING_SAVEHISTORY is not set.

I think that the corresponding source code logic is here:


Such logic doesn't match the feature name, which is ...SAVEHISTORY and not
...LOADHISTORY.

For example:
Busybox is often used in (emergency/disaster) recovery environments. There
is no need for any saving (readonly media). However it comes handy when
frequently used commands can be pre-loaded into the initramfs (for
interactive logins).

Is such a loadhistory-without-savehistory scenario tackled when changing:

#if MAX_HISTORY > 0 && ENABLE_FEATURE_EDITING_SAVEHISTORY

to

#if MAX_HISTORY > 0

in ash.c?

In case it is not, what more to change to allow loading a HISTFILE when
ENABLE_FEATURE_EDITING_SAVEHISTORY is not set?


What's the point of loading frequently used commands if you don't save what
you have typed *just now*? You can have .ash_history in a temp filesystem
if you like, but it still counts as saving the history.
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

ash.c history loading and ENABLE_FEATURE_EDITING_SAVEHISTORY

[Ceriel Jacobs]

It seems that BusyBox v1.27.2 doesn't load history from a history file 
when ENABLE_FEATURE_EDITING_SAVEHISTORY is not set.


I think that the corresponding source code logic is here:


Such logic doesn't match the feature name, which is ...SAVEHISTORY and 
not ...LOADHISTORY.


For example:
Busybox is often used in (emergency/disaster) recovery environments. 
There is no need for any saving (readonly media). However it comes handy 
when frequently used commands can be pre-loaded into the initramfs (for 
interactive logins).


Is such a loadhistory-without-savehistory scenario tackled when changing:

#if MAX_HISTORY > 0 && ENABLE_FEATURE_EDITING_SAVEHISTORY

to

#if MAX_HISTORY > 0

in ash.c?

In case it is not, what more to change to allow loading a HISTFILE when 
ENABLE_FEATURE_EDITING_SAVEHISTORY is not set?


Is such a change a candidate for an upstream patch?
___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox

Re: Question regarding runsvdir not reaping children.

[Laurent Bercot]

What is the rationale behind not reaping the children when the program 
exists? i run it from inittab as a respawn process and I get zombies 
when killing it when not reaping children alas the fix was pretty 
simple.


 Unless you're running runsvdir as process 1, there's no reason to do
so, because on runsvdir's death, its children will be reassigned to
init, and init will reap those zombies.

 If you're getting zombies when killing runsvdir, then you have
another problem, that is unrelated to runsvdir.

 Note that busybox init sometimes takes one second to reap zombies
(which is what you may have observed). This is a flaw in the design
and cannot be fixed without significantly rewriting it, but it
should not matter for practical purposes - zombies hanging around for
one second is generally not an issue.

--
 Laurent

___
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox