Re: Google searches requiring JavaScript (was Re: Can a Bash function be named "w3m" ?)

On Thursday 30 January 2025 10:13:39 am Richard Owlett wrote: > > On another, I've switched search-engine defaults from > > Google to (the HTML-only version of) DuckDuckGo. So far neither is > > giving me such an obviously superior experience for me to decide to > > switch the other machine over so

Re: Can a Bash function be named "w3m" ?

On Thu 30 Jan 2025 at 05:52:02 (-0800), Will Mengarini wrote: > * Roger Price [25-01/30=Th 13:59 +0100]: > > $wrongCodeForCheckingWhetherAliasExists && unalias w3m > > When I want to unalias something that might already be unaliased (as > when it's in .bashrc), I just code > unalias foo 2>/dev/

Re: Can a Bash function be named "w3m" ?

On Thu, Jan 30, 2025 at 11:17 AM Will Mengarini wrote: > [...] > Speaking of w3m, was anybody part of its dev team long enough > ago to know what happened to it? When I tried to join its > mailing list linked from I got > no response, even though I tried twice, a fe

Re: Google searches requiring JavaScript (was Re: Can a Bash function be named "w3m" ?)

On 1/30/25 8:15 AM, The Wanderer wrote: On 2025-01-30 at 08:52, Will Mengarini wrote: w3m needs some serious maintenance. It's still my favorite browser, but I hear Google is planning to start requiring Javascript for searches, so somebody's going to have to step up if w3m is to remain viable.

Re: Can a Bash function be named "w3m" ?

On Thu, 30 Jan 2025, Loris Bennett wrote: > Roger Price writes: > > [[ $(type -t w3m) == "w3m" ]] && unalias w3m > > Shouldn't that be > > [[ $(type -t w3m) == "alias" ]] && unalias w3m You are right! From the Bash man

Google searches requiring JavaScript (was Re: Can a Bash function be named "w3m" ?)

On 2025-01-30 at 08:52, Will Mengarini wrote: > w3m needs some serious maintenance. It's still my favorite browser, > but I hear Google is planning to start requiring Javascript for > searches, so somebody's going to have to step up if w3m is to remain > viable. Planning to? They already have -

Re: Can a Bash function be named "w3m" ?

* Roger Price [25-01/30=Th 13:59 +0100]: > $wrongCodeForCheckingWhetherAliasExists && unalias w3m When I want to unalias something that might already be unaliased (as when it's in .bashrc), I just code unalias foo 2>/dev/null because file descriptor 2 is the standard error output. > w3m() { /

Re: Can a Bash function be named "w3m" ?

Roger Price writes: > On a Debian 12 machine with bash 5.2.15-2+b7, I had this alias in my .bashrc > > alias w3m='/usr/bin/w3m -no-cookie -o auto-image=TRUE ' > > I understand that aliases are frowned on and should be written as functions, > so > I wrote

Re: Can a Bash function be named "w3m" ?

me w3m before defining the function. > POSIX sh only defines "foo()". > "function foo()" is therefore purely a bash extension. I stick to the basic definition of Bash functions. Roger

Re: Can a Bash function be named "w3m" ?

On Thu, Jan 30, 2025 at 08:18:26AM -0500, Greg Wooledge wrote: > On Thu, Jan 30, 2025 at 14:10:33 +0100, to...@tuxteam.de wrote: > > Try prefixing the thing with the builtin `function': > > > > function w3m() ... > > That would still leave the alias in place, though. So, both the alias > and t

Re: Can a Bash function be named "w3m" ?

elieve, if you actually try to run w3m at that point. You need to unalias w3m first. That's the real answer here. Also, just as a tangent, "function" is a bash extension that came from ksh. In ksh, there are two different ways to define a function: "foo()" and "functi

Re: Can a Bash function be named "w3m" ?

> > and received the error message > > > > bash: .bashrc: line 86: syntax error near unexpected token `(' > > bash: .bashrc: line 86: `w3m() { /usr/bin/w3m -no-cookie -o > > auto-image=TRUE $@ ; }' > > The problem is you *already* have the alias, and the

Re: Can a Bash function be named "w3m" ?

On Thu, Jan 30, 2025 at 13:59:37 +0100, Roger Price wrote: > alias w3m='/usr/bin/w3m -no-cookie -o auto-image=TRUE ' > w3m() { /usr/bin/w3m -no-cookie -o auto-image=TRUE $@ ; } > > and received the error message > > bash: .bashrc: line 86: syntax error near

Re: Can a Bash function be named "w3m" ?

On Thu, Jan 30, 2025 at 01:59:37PM +0100, Roger Price wrote: > On a Debian 12 machine with bash 5.2.15-2+b7, I had this alias in my .bashrc > > alias w3m='/usr/bin/w3m -no-cookie -o auto-image=TRUE ' > > I understand that aliases are frowned on and should be written

Can a Bash function be named "w3m" ?

On a Debian 12 machine with bash 5.2.15-2+b7, I had this alias in my .bashrc alias w3m='/usr/bin/w3m -no-cookie -o auto-image=TRUE ' I understand that aliases are frowned on and should be written as functions, so I wrote [[ $(type -t w3m) == "w3m" ]] && unalias w

Re: Bash expression to detect dying RAID devices

On Tue, 24 Dec 2024 15:45:31 +0100 (CET) Roger Price wrote: > File /proc/mdstat indicates a dying RAID device with an output > section such as > > md3 : active raid1 sdg6[0] > 871885632 blocks super 1.0 [2/1] [U_] > bitmap: 4/7 pages [16KB], 65536KB chunk > > Note the [U-]. Th

Re: Bash expression to detect dying RAID devices

On Tue, 24 Dec 2024, Greg Wooledge wrote: On Tue, Dec 24, 2024 at 15:45:31 +0100, Roger Price wrote: md3 : active raid1 sdg6[0] 871885632 blocks super 1.0 [2/1] [U_] bitmap: 4/7 pages [16KB], 65536KB chunk Note the [U-]. There isn't any [U-] in that output. There is [U_].

Re: Bash expression to detect dying RAID devices

Hi, On Tue, Dec 24, 2024 at 03:45:31PM +0100, Roger Price wrote: > I would like to scan /proc/mdstat and set a flag if [U-], [-U] or [--] > occur. Others have pointed out your '-' vs '_' confusion. But are you sure you wouldn't rather just rely on the "mdadm --monitor" command that emails you whe

Re: Bash expression to detect dying RAID devices

Roberto C. Sánchez (12024-12-24): > I think that '==' is the wrong tool. string1 == string2 string1 = string2 True if the strings are equal. = should be used with the test command for POSIX conformance. When used with the [[ command,

Re: Bash expression to detect dying RAID devices

On Tue, Dec 24, 2024 at 10:37:29 -0500, Roberto C. Sánchez wrote: > I think that '==' is the wrong tool. That is testing for string > equality, whilst you are looking for a partial match. This is what I was > able to get working after hacking on it for a minute or two: > &

Re: Bash expression to detect dying RAID devices

performs are trying to match '-' (which isn't part of the output). > My current attempt is > > #! /bin/bash -u > set -x > BAD=0; > while read L; > do if [[ $L == *"[U-]"* ]]; then B=1; fi; > if [[ $L == *"[-U]"* ]]; then B=1; f

Re: Bash expression to detect dying RAID devices

> File /proc/mdstat indicates a dying RAID device with an output section such > as > > md3 : active raid1 sdg6[0] >871885632 blocks super 1.0 [2/1] [U_] >bitmap: 4/7 pages [16KB], 65536KB chunk > > Note the [U-]. I can't see a "[U-]", only a "[U_]" Stefan

Re: Bash expression to detect dying RAID devices

On Tue, Dec 24, 2024 at 15:45:31 +0100, Roger Price wrote: > File /proc/mdstat indicates a dying RAID device with an output section such > as > > md3 : active raid1 sdg6[0] >871885632 blocks super 1.0 [2/1] [U_] >bitmap: 4/7 pages [16KB], 65536KB chunk > > Note the [U-]. There i

Re: Bash expression to detect dying RAID devices

Roger Price (12024-12-24): > File /proc/mdstat indicates a dying RAID device with an output section such > as Maybe try to find a more script-friendly source for that information in /sys/class/block/md127/md/? Regards, -- Nicolas George

Bash expression to detect dying RAID devices

set a flag if [U-], [-U] or [--] occur. My current attempt is #! /bin/bash -u set -x BAD=0; while read L; do if [[ $L == *"[U-]"* ]]; then B=1; fi; if [[ $L == *"[-U]"* ]]; then B=1; fi; if [[ $L == *"[--]"* ]]; then B=1; fi; done < /proc/mdstat

Re: Cleanup in a bash script

On Thu, Oct 03, 2024 at 03:19:09PM +0300, Anssi Saari wrote: > writes: > > > What actually happens seems completely different to me: the shell > > gets the EPIPE from the dying tee before it can see the EINTR, right? > > That depends. tee -i will ignore SIGINT but ./script gets it. So it can > k

Re: Cleanup in a bash script

writes: > What actually happens seems completely different to me: the shell > gets the EPIPE from the dying tee before it can see the EINTR, right? That depends. tee -i will ignore SIGINT but ./script gets it. So it can keep writing in the pipe, from the script proper or its SIGINT handler and e

Re: Cleanup in a bash script

Greg Wooledge (12024-10-02): > In that case, there are THREE foreground processes which receive a SIGINT: > > * The interactive shell, which ignores it, because interactive shells >always ignore SIGINT. You are very right on the rest, but this is a mistake: the interactive shell is not in th

Re: Cleanup in a bash script

On Wed, Oct 02, 2024 at 08:17:34AM -0400, Greg Wooledge wrote: [...] Thanks for your (as always) very exhaustive description. > What I'm mostly trying to convey here, though, is that signals do not > *propagate* from one process to another in any kind of automatic way. That's more or less what

Re: Cleanup in a bash script

ich ignores it, because interactive shells always ignore SIGINT. * The ./script process, which is presumably expanded to "/bin/bash ./script". * The tee -i log process. We know the interactive shell ignores it, and we can reasonably assume that the tee will accept it and terminate.

Re: Cleanup in a bash script

On Wed, Oct 02, 2024 at 02:43:11PM +0300, Anssi Saari wrote: > writes: [...] > > Explain to us what you really mean by "signals pass up the pipe", then > > things > > might become clearer. > > I realize I didn't spell it out. It's the, to me, obvious solution to > Tim's problem, as he wrote: >

Re: Cleanup in a bash script

yone else mention >> >> it. tee has had the -i option to ignore interrupt signals for ages. The >> >> non-obvious side effect is INT signals pass up the pipe, in your case to >> >> bash running your script. >> > >> > Signals don't "pass

Re: Cleanup in a bash script

ke this: > >> > > >> > ./script |& tee log > >> > > >> > and now it doesn't clean up if I it. > >> > >> Just a point here about tee since I didn't see anyone else mention > >> it. tee has had the -i optio

Re: Cleanup in a bash script

; and now it doesn't clean up if I it. >> >> Just a point here about tee since I didn't see anyone else mention >> it. tee has had the -i option to ignore interrupt signals for ages. The >> non-obvious side effect is INT signals pass up the pipe, in your case to >

Re: Cleanup in a bash script

ing? In this particular case it's almost certain that the tee program will have gone away before the bash script calls the exit handler. That last sentence seems _very_ relevant here. If the other end of the pipe is gone, then the shell builtin `echo` probably fails with SIGPIPE/EPIPE. So will

Re: Cleanup in a bash script

st a point here about tee since I didn't see anyone else mention > it. tee has had the -i option to ignore interrupt signals for ages. The > non-obvious side effect is INT signals pass up the pipe, in your case to > bash running your script. Signals don't "pass up the pipe&

Re: Cleanup in a bash script

re interrupt signals for ages. The non-obvious side effect is INT signals pass up the pipe, in your case to bash running your script.

Re: Cleanup in a bash script

g? > > In this particular case it's almost certain that the tee program will > have gone away before the bash script calls the exit handler. That last sentence seems _very_ relevant here. If the other end of the pipe is gone, then the shell builtin `echo` probably fails with SIGPIPE

Re: Cleanup in a bash script

On Sat, 28 Sep 2024, Greg Wooledge wrote: On Sat, Sep 28, 2024 at 14:53:10 +0100, Tim Woodall wrote: Is there a way in bash to guarantee that a trap gets called for cleanup in a script? #!/bin/bash trap cleanup EXIT cleanup() { ... } This works in bash -- i.e., it calls the cleanup

Re: Cleanup in a bash script

On Sat, Sep 28, 2024 at 15:17:47 +0100, Alain D D Williams wrote: > On Sat, Sep 28, 2024 at 10:13:59AM -0400, Greg Wooledge wrote: > > On Sat, Sep 28, 2024 at 14:53:10 +0100, Tim Woodall wrote: > > > Is there a way in bash to guarantee that a trap gets called for cleanup

Re: Cleanup in a bash script

On Sat, Sep 28, 2024 at 10:13:59AM -0400, Greg Wooledge wrote: > On Sat, Sep 28, 2024 at 14:53:10 +0100, Tim Woodall wrote: > > Is there a way in bash to guarantee that a trap gets called for cleanup > > in a script? > > #!/bin/bash > trap cleanup EXIT > cleanup() { &g

Re: Cleanup in a bash script

On Sat, Sep 28, 2024 at 14:53:10 +0100, Tim Woodall wrote: > Is there a way in bash to guarantee that a trap gets called for cleanup > in a script? #!/bin/bash trap cleanup EXIT cleanup() { ... } This works in bash -- i.e., it calls the cleanup function regardless of whether the shell

Re: Cleanup in a bash script

On 9/28/24 15:53, Tim Woodall wrote: Is there a way in bash to guarantee that a trap gets called for cleanup in a script? I have a script that works perfectly normally and cleans up after itself, even if it goes wrong. However on trying to debug something else, I wanted to run it like this

Cleanup in a bash script

Is there a way in bash to guarantee that a trap gets called for cleanup in a script? I have a script that works perfectly normally and cleans up after itself, even if it goes wrong. However on trying to debug something else, I wanted to run it like this: ./script |& tee log and now it doe

Re: BASH reference for those who are "learning by doing"?

On Tue, Sep 10, 2024 at 5:05 AM Anssi Saari wrote: > > Karl Vogel writes: > > > Have you tried some different fonts? My eyesight is poor, and a good > > font made all the difference. > > > > https://bezoar.org/posts/2023/0214/font-screenshots/ > > Fonts on what? I mostly can't control fonts on doc

Re: BASH reference for those who are "learning by doing"?

On Tuesday, 10-09-2024 at 18:59 Anssi Saari wrote: > George at Clug writes: > > > Have you tried 100 Hz or greater monitors? All my monitors are 60Hz. I > > wonder if these help with prolonged computer use? > > In my home setup one monitor does 75 Hz and the other 144 but I can't > see much

Re: BASH reference for those who are "learning by doing"?

Karl Vogel writes: > Have you tried some different fonts? My eyesight is poor, and a good > font made all the difference. > > https://bezoar.org/posts/2023/0214/font-screenshots/ Fonts on what? I mostly can't control fonts on documents I edit or create, for work at least. A little hard to do on

Re: BASH reference for those who are "learning by doing"?

George at Clug writes: > Have you tried 100 Hz or greater monitors? All my monitors are 60Hz. I > wonder if these help with prolonged computer use? In my home setup one monitor does 75 Hz and the other 144 but I can't see much, if any, difference in clarity compared to 60 Hz. Also I have no id

Re: BASH reference for those who are "learning by doing"?

On 10/9/24 08:13, Larry Martell wrote: What are these driving glasses? I can no longer drive at night and would love to know about them. They are glasses that are set to focus at long distance, so no good for desk. They correct for astigmatism, so at night instead of point lights such as

Re: BASH reference for those who are "learning by doing"?

On Sun, Sep 8, 2024 at 7:07 PM jeremy ardley wrote: > > > > On 9/9/24 06:23, George at Clug wrote: > > If I required glasses for reading the car's speedometer, then I would > > definitely be using a bifocal pair of glasses. So far I can easily read > > the instrument panel, and since most of the t

Re: BASH reference for those who are "learning by doing"?

On Mon Sep 9 09:07:11 2024 Anssi Saari wrote: > debian-u...@howorth.org.uk writes: > >> As a mere bifocal (well vari-focal) wearer can I suggest a different >> approach. Stop wearing tri-focals or any other variable focus specs >> for reading a computer screen. Tell them to get a [very cheap] p

Re: BASH reference for those who are "learning by doing"?

On 9/9/24 05:20, Karl Vogel wrote: On Mon 09 Sep 2024 at 04:47:20 (-0400), Anssi Saari wrote: I've used fixed focus glasses before but I find close range varifocals a huge upgrade. They're extremely useful for monitor work *and also* I can see and read things around me that fall outside the ext

Re: BASH reference for those who are "learning by doing"?

github.io/bash.txt, but it is less of a "learn by doing" and more of a quick cheat sheet that helps you write or read bash code. I assume that is also meant to be read using "outliner mode". The notes will give me practice in reading French which I haven't done since h

Re: Glasses for monitor work (was Re: BASH reference for those who are "learning by doing"?)

On 09/08/2024 12:12 PM, Stephen P. Molnar wrote: On 09/08/2024 12:17 PM, Steve McIntyre wrote: debian-u...@howorth.org.uk wrote: Richard Owlett wrote: [My examples are from my experiments with re-formatting text at https://ebible.org/engkjvcpb/ for comfortable reading by fellow tri-focal we

Re: BASH reference for those who are "learning by doing"?

.4) and got only an empty dark gray screen. You can also take a look at https://ychaouche.github.io/bash.txt, but it is less of a "learn by doing" and more of a quick cheat sheet that helps you write or read bash code. I assume that is also meant to be read using "outliner mode&quo

Re: BASH reference for those who are "learning by doing"?

On Monday, 09-09-2024 at 19:20 Karl Vogel wrote: > On Mon 09 Sep 2024 at 04:47:20 (-0400), Anssi Saari wrote: > > debian-u...@howorth.org.uk writes: > > > > > As a mere bifocal (well vari-focal) wearer can I suggest a different > > > approach. Stop wearing tri-focals or any other variable focus

Re: BASH reference for those who are "learning by doing"?

On Monday, 09-09-2024 at 18:46 Anssi Saari wrote: > debian-u...@howorth.org.uk writes: > > > As a mere bifocal (well vari-focal) wearer can I suggest a different > > approach. Stop wearing tri-focals or any other variable focus specs for > > reading a computer screen. Tell them to get a [very c

Re: BASH reference for those who are "learning by doing"?

On Mon 09 Sep 2024 at 04:47:20 (-0400), Anssi Saari wrote: > debian-u...@howorth.org.uk writes: > > > As a mere bifocal (well vari-focal) wearer can I suggest a different > > approach. Stop wearing tri-focals or any other variable focus specs for > > reading a computer screen. Tell them to get a [

Re: BASH reference for those who are "learning by doing"?

debian-u...@howorth.org.uk writes: > As a mere bifocal (well vari-focal) wearer can I suggest a different > approach. Stop wearing tri-focals or any other variable focus specs for > reading a computer screen. Tell them to get a [very cheap] pair of > single focus reading glasses made to suit the d

Re: BASH reference for those who are "learning by doing"?

On 9/9/24 06:23, George at Clug wrote: If I required glasses for reading the car's speedometer, then I would definitely be using a bifocal pair of glasses. So far I can easily read the instrument panel, and since most of the time we spend focusing on the traffic about us, a quick glance now an

Re: BASH reference for those who are "learning by doing"?

> single focus reading glasses made to suit the distance their screen is > away. > For any prolonged activity: 1) Like others who have responded, I do the above and recommend the same: "single focus reading glasses made to suit the distance the screen is away". Maintaining that distance is

Re: BASH reference for those who are "learning by doing"?

is in "** command line tricks" (https://i.imgur.com/eqBjD0n.png) You can also take a look at https://ychaouche.github.io/bash.txt, but it is less of a "learn by doing" and more of a quick cheat sheet that helps you write or read bash code. I use these two files (and more) to or

Re: Glasses for monitor work (was Re: BASH reference for those who are "learning by doing"?)

On 09/08/2024 12:17 PM, Steve McIntyre wrote: debian-u...@howorth.org.uk wrote: Richard Owlett wrote: [My examples are from my experiments with re-formatting text at https://ebible.org/engkjvcpb/ for comfortable reading by fellow tri-focal wearing senior citizens As a mere bifocal (well va

Re: Glasses for monitor work (was Re: BASH reference for those who are "learning by doing"?)

On 9/8/24 12:17, Steve McIntyre wrote: debian-u...@howorth.org.uk wrote: Richard Owlett wrote: [My examples are from my experiments with re-formatting text at https://ebible.org/engkjvcpb/ for comfortable reading by fellow tri-focal wearing senior citizens As a mere bifocal (well vari-focal)

Re: BASH reference for those who are "learning by doing"?

On Sun, Sep 08, 2024 at 04:43:20PM +0100, Brad Rogers wrote: > On Sun, 8 Sep 2024 16:25:04 +0100 > debian-u...@howorth.org.uk wrote: > > Hello debian-u...@howorth.org.uk, > > >Tell them to get a [very cheap] pair of single focus reading glasses > >made to suit the distance their screen is away.

Glasses for monitor work (was Re: BASH reference for those who are "learning by doing"?)

debian-u...@howorth.org.uk wrote: >Richard Owlett wrote: >> [My examples are from my experiments with re-formatting >> text at https://ebible.org/engkjvcpb/ for comfortable reading by >> fellow tri-focal wearing senior citizens > >As a mere bifocal (well vari-focal) wearer can I suggest a differen

Re: BASH reference for those who are "learning by doing"?

On Sun, 8 Sep 2024 16:25:04 +0100 debian-u...@howorth.org.uk wrote: Hello debian-u...@howorth.org.uk, >Tell them to get a [very cheap] pair of single focus reading glasses >made to suit the distance their screen is away. Exactly what I did. Sure, one /can/ use [bi|tri|vari]focals, but it's a ri

Re: BASH reference for those who are "learning by doing"?

Richard Owlett wrote: > [My examples are from my experiments with re-formatting > text at https://ebible.org/engkjvcpb/ for comfortable reading by > fellow tri-focal wearing senior citizens As a mere bifocal (well vari-focal) wearer can I suggest a different approach. Stop wearing tri-focals or a

Re: BASH reference for those who are "learning by doing"?

On Sun, Sep 08, 2024 at 06:48:30 +0200, Sirius wrote: > Bash has some nifty uses when it comes to variables. > > If you just want to store a file in a variable, > VAR="$( will do it. If you want to do an array instead, use the 'while read line; > do' construct. As ot

Re: BASH reference for those who are "learning by doing"?

tags & eliminating all CSS usage annoys some HTML5 purists ;] Instead of BASH and regular expression use some programming language where a reliable HTML parser is available. E.g. in python you may use lxml.html.html5parser, lxml.etree.HTMLParser, BeautifulSoup. Calibre aggressively st

Re: BASH reference for those who are "learning by doing"?

On 09/07/2024 06:51 PM, Greg Wooledge wrote: On Sat, Sep 07, 2024 at 22:00:27 +, Quaeryth wrote: A query like "site:stackoverflow.com bash how to read file into variable" via Google or DuckDuckGo (and maybe other search engines) usually points me in the right direction. Good luck

Re: BASH reference for those who are "learning by doing"?

On lör, 2024/09/07 at 10:50:36 -0500, Richard Owlett wrote: > This started with be exploring "regular expressions". > I discovered some tutorials that were using Bash in their samples. > One {lost the reference at the moment} was almost a match for a real > world problem

Re: BASH reference for those who are "learning by doing"?

noys some HTML5 purists ;] Instead of BASH and regular expression use some programming language where a reliable HTML parser is available. E.g. in python you may use lxml.html.html5parser, lxml.etree.HTMLParser, BeautifulSoup. Calibre aggressively strips CSS and some markup during conversion of

Re: BASH reference for those who are "learning by doing"?

On Sat, Sep 07, 2024 at 22:00:27 +, Quaeryth wrote: > A query like "site:stackoverflow.com bash how to read file into variable" via > Google or DuckDuckGo (and maybe other search engines) usually points me in > the right direction. Good luck with your experiments! What kind

Re: BASH reference for those who are "learning by doing"?

expressions) [...] >> useful puzzle to solve. > > I've got helpful references for regular expressions. Their examples use > Bash as the vehicle. I want to get my real world examples into Bash so I > can follow the example techniques given. > > [My examples are from my ex

Re: BASH reference for those who are "learning by doing"?

On 09/07/2024 03:46 PM, Quaeryth wrote: On 2024-09-07 11:50, Richard Owlett wrote: This started with be exploring "regular expressions". I discovered some tutorials that were using Bash in their samples. One {lost the reference at the moment} was almost a match for a real world prob

Re: BASH reference for those who are "learning by doing"?

On 2024-09-07 11:50, Richard Owlett wrote: > This started with be exploring "regular expressions". > I discovered some tutorials that were using Bash in their samples. > One {lost the reference at the moment} was almost a match for a real > world problem I have. > > Bu

Re: BASH reference for those who are "learning by doing"?

Richard Owlett wrote: > This started with be exploring "regular expressions". > I discovered some tutorials that were using Bash in their samples. > One {lost the reference at the moment} was almost a match for a real > world problem I have. > > But I've not use

Re: BASH reference for those who are "learning by doing"?

On 9/7/24 08:50, Richard Owlett wrote: This started with be exploring "regular expressions". I discovered some tutorials that were using Bash in their samples. One {lost the reference at the moment} was almost a match for a real world problem I have. But I've not used Bash i

BASH reference for those who are "learning by doing"?

This started with be exploring "regular expressions". I discovered some tutorials that were using Bash in their samples. One {lost the reference at the moment} was almost a match for a real world problem I have. But I've not used Bash in eons and have forgotten how to read

Re: bash history

This is how I keep a long-term record of bash commands from different sessions: https://www.reddit.com/r/bash/comments/ak9c3r/ HTH -- Karl Vogel I don't speak for anyone but myself Comment: I use a screwdriver a lot Reply: I'm all out of orange juice. Wil

Re: bash history

starting up again. Yes. Setting HISTFILE is one way to control that. It is not uncommon for folks to do something like: HISTFILE=~/.history.${HOSTNAME} when using a shared file system (e.g., NFS). In bash, the history built-in takes a filename for most options. So you can do something like: history -r

Re: bash history

On Sat, Jul 27, 2024 at 11:23 PM Jeffrey Walton wrote: > On Sun, Jul 28, 2024 at 12:25 AM Mike Castle wrote: > > * I keep history under source control (currently git) and regularly > > (well, for some definition of "regularly"), merge them across machines > > This is an unusual use case (to me).

Re: bash history

On Sat, Jul 27, 2024 at 11:04 PM mick.crane wrote: > If I've "su'd" I type "exit". > To close the terminal I click that X in the virtual terminal's top right > hand corner. Depending on settings, that may or may not save that invocation's history. You'll likely want to test to verify that it doe

Re: bash history

On 2024-07-28 at 09:29, Yassine Chaouche wrote: > Le 7/28/24 à 12:19, songbird a écrit : > >> to keep my own setup consistent and to not keep certain things in >> history i actually do the opposite of what you want because i want >> certain commands already preloaded in my history for all windows

Re: bash history

Le 7/28/24 à 12:19, songbird a écrit : [...] to keep my own setup consistent and to not keep certain things in history i actually do the opposite of what you want because i want certain commands already preloaded in my history for all windows when i start up and then i adjust my environment b

Re: bash history

mick.crane wrote: > In debian bookworm, xfce desktop, different virtual terminals have a > different history if same user presses "up key" in different virtual > terminals ? > Is this something that can be changed so history is shared between > virtual terminals? > mick not that i would want

Re: bash history

just shy of 180,000 commands. It would likely be less if I turned on the "erasedups" feature, but I like to keep the context. And I've seen comments about folks who have multiple decades of shell history. On modern machines, it simply isn't an issue. mrc I second Mike Cas

Re: bash history

On 2024-07-27 23:58, Greg Wooledge wrote: You need to specify *exactly* what you're doing. "exactly" is at mickiwiki.com I can take the ridicule of my coding understanding. Whenever I need to reboot my computer (kernel update or the like), I decide which shells I want to retain history from,

Re: bash history

On Sun, Jul 28, 2024 at 12:25 AM Mike Castle wrote: > > On Sat, Jul 27, 2024 at 2:50 PM mick.crane wrote: > > Is this something that can be changed so history is shared between > > virtual terminals? > > [...] > For me, I see up bash with the following features: > *

Re: bash history

see the history in a new terminal, where I "cd'd" to for example. stuff like that. No, I mean *how did you close the terminal*? And what terminal is it? one of these 1826 ?Sl 0:00 xfce4-terminal 1854 pts/0Ss 0:00 bash If I've "su'd" I type

Re: bash history

efault configuration is likely different across each one (bash vs ksh vs zsh vs csh), and what values you need to change to achieve what you want varies between them as well. Everything you need should be available through the install manual pages, accessible via the command "man bash". Search

Re: bash history

On 28/07/2024 08:01, mick.crane wrote: Sometimes I forget where I was after closing a virtual terminal  and it would be handy to see the history in a new terminal, where I "cd'd" to for example. help history less ~/.bash_history

Re: bash history

program and then clicking the window. Or, you might have too many history lines in memory at the time you exit the shell, and the cd command that you wanted to find might be dropped because it was too far in the past. (Bash only stores 500 lines of history by default.)

Re: bash history

On 2024-07-27 23:58, Greg Wooledge wrote: You need to specify *exactly* what you're doing. My project management skills are non-existent. If I have a script that is working I'll copy to eg. script2 and make changes to that. Sometimes, depending, I'll have similar things in other directories t

Re: bash history

On 2024-07-27 22:50:17 +0100, mick.crane wrote: > In debian bookworm, xfce desktop, different virtual terminals have a > different history if same user presses "up key" in different virtual > terminals ? > Is this something that can be changed so history is shared between virtual > terminals? This

Re: bash history

er presses "up key" in >>> different virtual terminals ? >> >> As your subject says, this is "bash history". And yes, each >> instance of bash has its own separate history. It has nothing to >> do with your terminal emulator or your deskto

Re: bash history

me user presses "up key" in different virtual > > > terminals ? > > > > As your subject says, this is "bash history". And yes, each instance of > > bash has its own separate history. It has nothing to do with your > > terminal emulator or your d

Re: bash history

On 2024-07-27 23:08, Greg Wooledge wrote: On Sat, Jul 27, 2024 at 22:50:17 +0100, mick.crane wrote: In debian bookworm, xfce desktop, different virtual terminals have a different history if same user presses "up key" in different virtual terminals ? As your subject says, this is &qu

Re: bash history

Hi, On Sat, Jul 27, 2024 at 10:50:17PM +0100, mick.crane wrote: > Is this something that can be changed so history is shared between virtual > terminals? You may be interested in "atuin" to aggregate shell history from multiple logins and machines in a searchable interface. It can be self-hosted.

  1   2   3   4   5   6   7   8   9   10   >