Comments (6)
maybe until this gets resolved, someone (preferably a shell master) could write a properly working bash-history emulation using a .yashrc snippet like the one i posted in the original bug report on osdn. the one i use is "good enuff" but far from perfect, and it still doesn't work (i.e. not update the histfile) when SIGHUP is sent.
the current version i use is this:
MYHISTF=~/.yash_history_raw
test -e "$MYHISTF" || touch "$MYHISTF"
history -r "$MYHISTF"
MYHISTF_LINES=$(history | wc -l)
save_hist() {
history -w "$MYHISTF".$$
nl_count=$(wc -l "$MYHISTF".$$ | cut -d " " -f 1)
added=$((nl_count - MYHISTF_LINES))
{
flock -x 3
tail -n $added "$MYHISTF".$$ >> "$MYHISTF"
flock -u 3
} 3>"$MYHISTF".lock
rm -f "$MYHISTF".$$ "$MYHISTF".lock
}
#trap 'exec </dev/null' HUP
trap save_hist TERM EXIT
fi
from yash.
To minimize the possibility of loss of data, the shell should write to the history file immediately after each command is entered, which is the current behavior. The shell reads the history file every time it prompts for a new command, which is also the current behavior but can be undesirable as the user may want to see the history of the current session only. It may be possible for the shell not to reflect new entries from the file so that each session will have its own view of linear history. The basic idea to achieve this is to add a flag for each entry in the shell session which indicates whether the entry is visible in that session.
Unresolved questions:
- How are entries numbered? Do separate sessions need to cooperate to avoid collisions?
- If we keep the current behavior of writing each command to the file immediately, the file will contain an interspersed list of commands from different sessions, and a new session will start with that list. Can we organize the history so that all entries from a session are grouped together?
- Do we need to change the history file refreshing mechanism to support this?
- Do sessions can safely coexist when some of them have this feature enabled and some don't?
from yash.
One possible scheme:
- the history file is loaded into memory at startup
- each shell immediately writes history to the history file AND into to the in-memory copy
- after the initial load from disk, history is only ever read from the in-memory copy.
The only thing that could be annoying about this is that sometimes you do actually want to get a history line that was created by another shell, but was added to history since your current shell has started.
I think ideally I'd like a scheme where history from all instances is available, but history from the current shell is given priority. I don't know how to efficiently implement that though...
Difficult problem... How does fish shell do it?
from yash.
You could do something like:
- At startup, give each shell a "probably unique" ID (say, a random 32/64-bit number)
- When writing a history line into the history file, include the ID of the shell with the line.
- When searching history, prioritise entries with the current shell's ID, but maintain the order of all entries with the same identifier.
In the rare case of a identifier collision, the user would see some history from another shell...
Supposing there is a collision, the chances of two active shells having the same ID is even more slim. It's way more likely that the collision is with a long-dead shell, meaning that history entries from the dead shell will be older than the current-shell's entries.
This means that pressing the up arrow is highly likely to only show the previous entry from the current shell.
from yash.
A refinement to the above: when an instance writes it's first line of history into the histfile, it could check that no other entry in the file used the same ID. If one did, it should re-generate its ID and check again (until there are no collisions).
I don't think this can be made totally race free (without something like advisory locks, which might be a bad idea for a shell), but it minimises the probability of an ID collision yet more.
from yash.
Having thought about this more:
For now, I'm considering adding only the first option rather than implementing the both options at once.
This would give users most of what they'd want.
If at some point you want to get history items from anther shell, you could do exec yash
.
from yash.
Related Issues (20)
- Non-interactive shell should not ignore stop signals
- Result of tilde expansion in nested parameter expansion
- 'typeset' and family accept invalid identifiers
- Cannot expand `${0_1}`
- Orphan trailing backslash in pattern
- Numeric brace expansion containing parameter
- Filtering completion candidates incrementally
- seg fault in alt+c completion HOT 6
- Many linting errors on man page. HOT 2
- Build warnings on OpenBSD. HOT 9
- AddressSanitizer: negative-size-param in decompose_paths HOT 6
- for loop wrong exit status HOT 5
- doas completion
- b$ is printed when resizing kitty HOT 5
- Post-prompt command HOT 2
- filename completion with tab inserts additional backslash if started from one HOT 4
- Support for cross compilation HOT 2
- fsplit-p.tst: export IFS influences run-test.sh HOT 2
- Accidentally pressing escape will wreck interactive input until next Ctrl+C HOT 2
- Yash Throws: yash: parameter `DIRENV_DIR' is not set When Accounted For HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from yash.