Re: [PATCH] Correct error message when using -n and -o ignoreeof in interactive mode
On 2024-08-18 at 11:21 +0700, Robert Elz wrote: > Interactive shells with -n (noexec) set are pointless The man page states: > -n Read commands but do not execute them. This may be used > to check a shell script for syntax errors. This is ig‐ > nored by interactive shells. And indeed, doing a set -n on an interactive shell is ignored. It is however possible to run an interactive noexec bash if it is set on launch.
Re: please make the commit log clean
On Mon, 19 Aug 2024 at 06:45, shynur . wrote: > I believe these output files should be added to `.gitignore` and generated > during the `make` process. Not doing so is deliberate in some cases. In an ideal world, yes they should be generated during `make`, but that would increase the "build toolset" that everyone would have to install, including people who are writing code patches rather than documentation. Otherwise, they will severely pollute the commit history, making it much > harder for future maintainers to understand and manage the repository. > As long as the generated files start with a "generated from" comment, it's not really a great imposition on developers. There are much bigger learning issues than managing the documentation. Perhaps a compromise would be to put the documentation in a directory that's not inside the source code directory, so it's easier to `git diff` just one or the other. (In practice, that would mean moving some of the code into a new subdirectory.) -Martin
[PATCH] bash_source_fullpath: add to reset_shopt_options
This was actually caught by the test suite
---
builtins/shopt.def | 1 +
tests/shopt.right | 4
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/builtins/shopt.def b/builtins/shopt.def
index 67bc0c22..37fda11e 100644
--- a/builtins/shopt.def
+++ b/builtins/shopt.def
@@ -357,6 +357,7 @@ void
reset_shopt_options (void)
{
autocd = cdable_vars = cdspelling = 0;
+ bash_source_fullpath = 0;
check_hashed_filenames = CHECKHASH_DEFAULT;
check_window_size = CHECKWINSIZE_DEFAULT;
allow_null_glob_expansion = glob_dot_filenames = 0;
diff --git a/tests/shopt.right b/tests/shopt.right
index e4ab12c0..80a42814 100644
--- a/tests/shopt.right
+++ b/tests/shopt.right
@@ -310,9 +310,5 @@ xtrace off
--
./shopt.tests: line 106: shopt: xyz1: invalid shell option name
./shopt.tests: line 107: shopt: xyz1: invalid option name
-4c4
-< bash_source_fullpath on
-> bash_source_fullpath off
expand_aliases on
expand_aliases on
--
2.46.0
Bash History Behavior Suggestion
Version: GNU bash, version 5.2.15(1)-release (x86_64-pc-linux-gnu) OS: Linux 6.1.0-23-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.99-1 (2024-07-15) x86_64 GNU/Linux Issue: History Behavior For up-arrow completion, I think restricting to the history of the current bash session is the correct behavior, but for invocations of the 'history' built-in command, being able to search across all sessions (past and present) is sometimes more useful. I would suggest: 1. Append to history file immediately on each command. 2. Restrict up-arrow completion to the history of present session. 3. Add column(s) to the history file to identify the session the command came from (pty, pid, etc). 4. Add options to the 'history' command to toggle between session-local and global reporting.
Re: Bash History Behavior Suggestion
On Mon, Aug 19, 2024 at 15:52:22 -0400, supp...@eggplantsd.com wrote: > I would suggest: > 2. Restrict up-arrow completion to the history of present session. This is going to be an *extremely* unpopular suggestion. Though, I must wonder: do you literally mean *only* the up-arrow (or Ctrl-P or ESC k), or do you also include searching from within the interactive shell's editing modes (Ctrl-R or ESC /)? My own usage pattern includes using ESC / to bring up a historic command from a past session. I do this a *lot*. I suspect others may share that pattern, albeit possibly with the emacs key binding instead of the vi one. I don't know how common it is to use the up arrow (or equivalent) to bring up a command from a past session. I've done it a few times -- usually when I'm trying to answer someone's question, and I launch a temporary shell window to do so, get my answer, paste it to them, close the window -- and then suddenly they change the question. So I open another new window, and bring up the command(s) I was just using in the previous window, modify them, etc.
Re: please make the commit log clean
2024年8月20日(火) 2:25 Martin D Kealey : > Perhaps a compromise would be to put the documentation in a directory > that's not inside the source code directory, so it's easier to `git diff` > just one or the other. (In practice, that would mean moving some of the > code into a new subdirectory.) One can put " diff=no" in .git/info/attributes to ignore these files in `git diff'. Mine is something like /configure diff=no *.cache diff=no /m4/* diff=no /po/*.gmo diff=no /po/*.po diff=no /doc/bashref.aux diff=no /doc/bashref.bt diff=no /doc/bashref.bts diff=no /doc/bashref.cp diff=no /doc/bashref.cps diff=no /doc/bashref.dvi diff=no /doc/bashref.fn diff=no /doc/bashref.fns diff=no /doc/bashref.html diff=no /doc/bashref.info diff=no /doc/bashref.ky diff=no /doc/bashref.log diff=no /doc/bashref.pdf diff=no /doc/bashref.pg diff=no /doc/bashref.ps diff=no /doc/bashref.rw diff=no /doc/bashref.rws diff=no /doc/bashref.tmp diff=no /doc/bashref.toc diff=no /doc/bashref.tp diff=no /doc/bashref.vr diff=no /doc/bashref.vrs diff=no /doc/bash.html diff=no /doc/bash.info diff=no /doc/bash.pdf diff=no /doc/bash.ps diff=no /doc/builtins.0 diff=no /doc/builtins.pdf diff=no /doc/builtins.ps diff=no /doc/bash.0 diff=no /doc/rbash.0 diff=no
Re: please make the commit log clean
2024年8月20日(火) 5:52 Koichi Murase : > 2024年8月20日(火) 2:25 Martin D Kealey : > > Perhaps a compromise would be to put the documentation in a directory > > that's not inside the source code directory, so it's easier to `git diff` > > just one or the other. (In practice, that would mean moving some of the > > code into a new subdirectory.) > > One can put " diff=no" in .git/info/attributes to > ignore these files in `git diff'. Mine is something like I forgot to mention that I I have the following lines in my ~/.gitconfig: [diff "no"] command = /bin/true
Re: Bash History Behavior Suggestion
The following suggestions, or close approximations, can all be implemented
using the existing facilities.
On Tue, 20 Aug 2024 at 05:52, wrote:
> I would suggest:
>
> 1. Append to history file immediately on each command.
>
Easily done by putting `history -a` into `PROMPT_COMMAND`
2. Restrict up-arrow completion to the history of present session.
>
That's easy. Simply don't use `history -r` in your .bashrc or
/etc/bash/bashrc.
(Unfortunately modifying the latter will require admin access to your host,
so choose a distro that does NOT include `history -r` among its system-wide
shell start-up files.)
3. Add column(s) to the history file to identify the session the command
> came from (pty, pid, etc).
>
I simply write the history for each session into a separate file; I have
HISTFILE=$HOME/.bash_history.d/$EPOCHSECONDS.$TTY.$$
That way I can simply use a pager such as `less` to read the file I'm
interested in. If I want to see the timestamps, I can use:
( HISTTIMEFMT="%F,%T " HISTFILE={other-history-file} ; history -c ;
history -r ; history ) | less
4. Add options to the 'history' command to toggle between session-local
> and global reporting.
>
I simply use separate commands to view the current session's history vs all
sessions.
I generally prefer not to interleave multiple sessions, but on the rare
occasion when I do want this, I can simply use:
( cd $HOME/.bash_history.d ; HISTTIMEFORMAT="%F,%T " ; for HISTFILE in * ;
do ( history -c ; history -r ; history ) ; done ) | sort | less
If I did this often enough to actually care, I'd wrap it in a function.
Re: Bash History Behavior Suggestion
sorry, I meant HISTTIMEFORMAT rather than HISTTIMEFMT
On Tue, 20 Aug 2024 at 14:58, Martin D Kealey
wrote:
> The following suggestions, or close approximations, can all be implemented
> using the existing facilities.
>
> On Tue, 20 Aug 2024 at 05:52, wrote:
>
>> I would suggest:
>>
>> 1. Append to history file immediately on each command.
>>
>
> Easily done by putting `history -a` into `PROMPT_COMMAND`
>
> 2. Restrict up-arrow completion to the history of present session.
>>
>
> That's easy. Simply don't use `history -r` in your .bashrc or
> /etc/bash/bashrc.
>
> (Unfortunately modifying the latter will require admin access to your
> host, so choose a distro that does NOT include `history -r` among its
> system-wide shell start-up files.)
>
> 3. Add column(s) to the history file to identify the session the command
>> came from (pty, pid, etc).
>>
>
> I simply write the history for each session into a separate file; I have
>
> HISTFILE=$HOME/.bash_history.d/$EPOCHSECONDS.$TTY.$$
>
> That way I can simply use a pager such as `less` to read the file I'm
> interested in. If I want to see the timestamps, I can use:
>
> ( HISTTIMEFMT="%F,%T " HISTFILE={other-history-file} ; history -c ;
> history -r ; history ) | less
>
> 4. Add options to the 'history' command to toggle between session-local
>> and global reporting.
>>
>
> I simply use separate commands to view the current session's history vs
> all sessions.
> I generally prefer not to interleave multiple sessions, but on the rare
> occasion when I do want this, I can simply use:
>
> ( cd $HOME/.bash_history.d ; HISTTIMEFORMAT="%F,%T " ; for HISTFILE in *
> ; do ( history -c ; history -r ; history ) ; done ) | sort | less
>
> If I did this often enough to actually care, I'd wrap it in a function.
>
Re: Bash History Behavior Suggestion
I know it can. The suggestion is that the default behavior needs some
work:
https://askubuntu.com/questions/67283/is-it-possible-to-make-writing-to-bash-history-immediate
https://askubuntu.com/questions/80371/bash-history-handling-with-multiple-terminals
https://askubuntu.com/questions/885531/half-of-bash-history-is-missing
https://askubuntu.com/questions/261407/how-to-save-terminal-history-manually
On 2024-08-20 12:58 am, Martin D Kealey wrote:
The following suggestions, or close approximations, can all be
implemented
using the existing facilities.
On Tue, 20 Aug 2024 at 05:52, wrote:
I would suggest:
1. Append to history file immediately on each command.
Easily done by putting `history -a` into `PROMPT_COMMAND`
2. Restrict up-arrow completion to the history of present session.
That's easy. Simply don't use `history -r` in your .bashrc or
/etc/bash/bashrc.
(Unfortunately modifying the latter will require admin access to your
host,
so choose a distro that does NOT include `history -r` among its
system-wide
shell start-up files.)
3. Add column(s) to the history file to identify the session the
command
came from (pty, pid, etc).
I simply write the history for each session into a separate file; I
have
HISTFILE=$HOME/.bash_history.d/$EPOCHSECONDS.$TTY.$$
That way I can simply use a pager such as `less` to read the file I'm
interested in. If I want to see the timestamps, I can use:
( HISTTIMEFMT="%F,%T " HISTFILE={other-history-file} ; history -c ;
history -r ; history ) | less
4. Add options to the 'history' command to toggle between session-local
and global reporting.
I simply use separate commands to view the current session's history vs
all
sessions.
I generally prefer not to interleave multiple sessions, but on the rare
occasion when I do want this, I can simply use:
( cd $HOME/.bash_history.d ; HISTTIMEFORMAT="%F,%T " ; for HISTFILE in
* ;
do ( history -c ; history -r ; history ) ; done ) | sort | less
If I did this often enough to actually care, I'd wrap it in a function.
Re: Bash History Behavior Suggestion
On Tue, Aug 20, 2024, at 1:42 AM, supp...@eggplantsd.com wrote: > The suggestion is that the default behavior needs some work The default behavior is unlikely to change. For every cherry-picked example of someone unsatisfied with it (bugs aside), there is likely someone else who prefers it as is (or at least would not appreciate it changing out from under them). New shopt settings may be doable. -- vq
Re: Bash History Behavior Suggestion
I wouldn't consider dozens of stackoverflow/askubuntu/etc complaints of missing/disappearing history "cherry-picked". There were far more than I sent. I understand not wanting to pull the rug out from under people, but the kludges Kealey posted were inelegant. An opt-in for the suggested behavior would be good enough. JS On 2024-08-20 2:17 am, Lawrence Velázquez wrote: On Tue, Aug 20, 2024, at 1:42 AM, supp...@eggplantsd.com wrote: The suggestion is that the default behavior needs some work The default behavior is unlikely to change. For every cherry-picked example of someone unsatisfied with it (bugs aside), there is likely someone else who prefers it as is (or at least would not appreciate it changing out from under them). New shopt settings may be doable.
