PayPal Notification ( Your account can be suspended )
Dear PayPal Member, PayPal is committed to maintaining a safe environment for its community of buyers and sellers. To protect the security of your account, PayPal employs some of the most advanced security systems in the world and our anti-fraud teams regularly screen the PayPal system for unusual activity. Recently, our Account Review Team identified some unusual activity in your account. In accordance with PayPal's User Agreement and to ensure that your account has not been compromised, access to your account was flagged. Your account will remain flagged until this issue has been resolved. This is a fraud prevention measure meant to ensure that your account is not compromised. In order to secure your account and quickly restore full access, we may require some specific information from you for the following reason: Our system requires further account verification. Case ID Number: PP-056-245-481 We encourage you to log in and restore full access as soon as possible. Should your account remain flagged for an extended period of time, it may result in further limitations on the use of your account or may result in eventual account closure. --- Please click on the link below to log in and restore full access to your account. https://www.paypal.com/cgi-bin/webscr?cmd=_login-run -- Thank you for your prompt attention to this matter. Please understand that this is a security measure meant to help protect you and your account. We apologize for any inconvenience. Sincerely, PayPal Account Review Department PayPal Email ID PP562 -- This message was scanned for spam and viruses by BitDefender. For more information please visit http://linux.bitdefender.com/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Du wirst zum Sklaven gemacht!!!
Lese selbst: http://globalfire.tv/nj/05de/globalismus/db_walter.htm Immer mehr Frauen prostituieren sich: http://shortnews.stern.de/web/id/557817/robot/1/x_id/Immer%20mehr%20Frauen%20prostituieren%20sich,%20damit%20sie%20ihre%20Kinder%20ern%E4hren%20k%F6nnen/start.cfm STAATSPROPAGANDA: http://www.spiegel.de/wirtschaft/0,1518,343698,00.html ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Verbrechen der deutschen Frau
Lese selbst: http://www.jn-bw.de/texte/zeitgeschichte/verbrechen_der_frau.htm ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Tuerkei in die EU
GEWALTEXZESS: http://www.spiegel.de/politik/ausland/0,1518,345203,00.html Politiker zerreißt Menschenrechtsbericht: http://www.spiegel.de/politik/ausland/0,1518,325983,00.html Schily = Hitler http://www.spiegel.de/politik/deutschland/0,1518,345929,00.html Schily wehrt sich gegen Hitler-Vergleiche: http://www.spiegel.de/politik/deutschland/0,1518,345749,00.html Sie hat ja wie eine Deutsche gelebt: http://www.spiegel.de/panorama/0,1518,342484,00.html http://www.npd.de/npd_info/deutschland/2005/d0205-31.html Parallelgesellschaften - Feind hoerte mit: http://www.npd.de/npd_info/meldungen/2005/m0305-15.html Sie war unerlaubt spazieren: http://www.taz.de/pt/2004/11/25/a0143.nf/text Tiere an Autobahn geschlachtet: http://forum.gofeminin.de/forum/actu1/__f384_actu1-TuRKEI-NEIN-DANKE.html ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
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
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
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.
Re: Bash History Behavior Suggestion
Bash or no bash, spreading history over dozens of files in
`bash_history.d/` is yuck. We already have a comment with the timestamp
in `.bash_history`. If I were implementing the suggestion, I would add
more information to the comment, then add two new flags to the `history`
command that filter+output the file (i.e. not the internal history
list): `--global` to display everything in `.bash_history`, and
`--local` to restrict output to entries from the current session.
Everything else would remain as-is.
So this:
#1724136363
man bash
Becomes this:
#1724136363 [sess create time] [sess PID] [sess TTY]
man bash
I think it is important to add the local/global flags because it gives
us some leeway as to how that comment is structured. If you take the
line of "that's what grep is for", then we're committed to the v1 format
forever after.
The problem with the stackoverflow solutions is that they are
all-or-nothing: either mash the history together across all sessions,
but get strange behavior on history nav & expansion, or don't mash, be
cut-off from information in concurrent sessions, and end up with the
occasional unsaved session. Being able to filter the file directly lets
us look things up without having to slice-and-splice into the internal
history.
On 2024-08-20 6:14 am, Martin D Kealey wrote:
"Missing/disappearing history" is entirely down to the lack of "writing
history as you go", and yes that would be reasonable to offer as a new
opt-in feature.
As for separation of sessions, I strongly suspect that anything between
*total* separation and *none* will result in so many ugly compromises
that
in the end almost nobody will be happy with it. So if there's to be an
additional option - which I'm not convinced of - I suggest that it
simply
be to set HISTFILE by default to either
$HOME/.bash_history.d/{some-pattern-here} (if the directory exists) or
~/.bash_history (matching the current behaviour when that directory
does
not exist). I would recommend that the pattern include most or all of
$$,
$TTY, $LOGNAME, and $((EPOCHSECONDS-SECONDS)).
Lastly, an awful lot of "default behaviour" is down to whatever
/etc/skel/.bashrc and /etc/bash/bashrc that are shipped with Bash by
the
various distros. Maybe Bash should start shipping some kind of
"standard
library" of functions that are *expected* to be included with any
distro,
but are not actually built into the binary.
-Martin
PS: complaining about "inelegant" in relation to Bash seems a bit
pointless.
On Tue, 20 Aug 2024 at 16:48, wrote:
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.
Re: Bash History Behavior Suggestion
The problem with the tagged format is that it's *not* usable by grep
Awk would have no problem with it.
limited to exactly whatever magic is built into the "history" command
That's where the magic should be. If that were the official interface
to `.bash_history`, then bash has freedom to innovate on what is stored,
and how it is stored. Then we could add even more information.
Would that be few enough files to satisfy you?
My itch has already been scratched--albeit with a rat's nest of scripts
and configurations. With a better history implementation, that could be
done away with. Migrating to multiple files for such a low-bandwidth
application seems like replacing one rat's nest with another. It would
be every bit as brittle as what bash is already doing.
Another option would be to provide a more robust hook for using your own
history provider. I put my tweaks in PROMPT_COMMAND, but if we had a
HISTAPPEND_COMMAND, we could pass it environment variables relating to
all aspects of the last command--start time, end time, cpu, working dir,
PID, TTY, etc.
There are several external history providers out there, but they seem to
need hundreds of lines of bash to do a proper integration. Making it
easier for those tools to capture everything bash knows related to a
command would easily halve the size and complexity of those integration
scripts.
I've attached an example integration script for https://atuin.sh/. I
don't use it myself. I only mention it because it seems to be the most
popular one.
You can see that only around 25% of the script is for keybinds and
retrieval; the rest is for setting up the capture.
Fields of interest, a running list:
- shell start time
- shell PID
- shell TTY
- command start time (milli/micro)
- command end time (milli/micro)
- command CPU real/user/sys
- command exit code
- command working directory
On 2024-08-20 12:35 pm, Martin D Kealey wrote:
The problem with the tagged format is that it's *not* usable by grep,
so
you're limited to exactly whatever magic is built into the "history"
command.
"Yuck" is in the eye of the beholder. I've tried numerous other ways to
segregate sessions, and IMO multiple files was the "least yuck" of many
worse options.
All that said, I would like *some* additional information recorded in
the
history file, especially $PWD (when it changes - interpreting "popd"
requires significant mental effort when reading a history file), and
$BASHPID (to track nested shells). With those I would be happy to have
~/.bash_history.d/$TTY, which would greatly reduce the number of files.
Would that be few enough files to satisfy you?
-Martin
On Wed, 21 Aug 2024, 00:38 , wrote:
Bash or no bash, spreading history over dozens of files in
`bash_history.d/` is yuck. We already have a comment with the
timestamp
in `.bash_history`. If I were implementing the suggestion, I would add
more information to the comment, then add two new flags to the
`history`
command that filter+output the file (i.e. not the internal history
list): `--global` to display everything in `.bash_history`, and
`--local` to restrict output to entries from the current session.
Everything else would remain as-is.
So this:
#1724136363
man bash
Becomes this:
#1724136363 [sess create time] [sess PID] [sess TTY]
man bash
I think it is important to add the local/global flags because it gives
us some leeway as to how that comment is structured. If you take the
line of "that's what grep is for", then we're committed to the v1
format
forever after.
The problem with the stackoverflow solutions is that they are
all-or-nothing: either mash the history together across all sessions,
but get strange behavior on history nav & expansion, or don't mash, be
cut-off from information in concurrent sessions, and end up with the
occasional unsaved session. Being able to filter the file directly
lets
us look things up without having to slice-and-splice into the internal
history.
On 2024-08-20 6:14 am, Martin D Kealey wrote:
> "Missing/disappearing history" is entirely down to the lack of "writing
> history as you go", and yes that would be reasonable to offer as a new
> opt-in feature.
>
> As for separation of sessions, I strongly suspect that anything between
> *total* separation and *none* will result in so many ugly compromises
> that
> in the end almost nobody will be happy with it. So if there's to be an
> additional option - which I'm not convinced of - I suggest that it
> simply
> be to set HISTFILE by default to either
> $HOME/.bash_history.d/{some-pattern-here} (if the directory exists) or
> ~/.bash_history (matching the current behaviour when that directory
> does
> not exist). I would recommend that the pattern include most or all of
> $$,
> $TTY, $LOGNAME, and $((EPOCHSECONDS-SECONDS)).
>
> Lastly, an awful lot of "default behaviour" is down to whatever
> /etc/skel/.bashrc and /etc/bash/bashrc that are shipped with Bash by
>
Re: Re: Question
Auto-response to "Re: Question" Thank you for your email! It will be read and answered within the next two or three days. In order to keep this service free, we need to streamline the support process. Your help is deeply appreciated. To that goal, we request that ALL SUPPORT REQUESTS CONTAIN THE FOLLOWING THREE ITEMS. If your recent email did not have them, you have a chance to redeem yourself *now* by sending a second email with the complete information. (You probably won't get this autoresponse then.) "I don't know" or "There was no error message" are acceptable answers, but you need to at least try! In order for us to help you, WE NEED: - The exact URL (web address) of the actual form in question, - The HTML (source code) for the *entire* page (really!), - The exact error message, if you see one. Thanks again for your understanding! We'll be back to you soon. -- David Beroff <[EMAIL PROTECTED]> ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
