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
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
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
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
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.
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:
>
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
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
; 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
>
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
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 interrupt signals for ages. The
non-obvious side effect is INT signals pass up the pipe, in your case to
bash running your 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
.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
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
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
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 [
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
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
> 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
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
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
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)
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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).
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
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
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
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
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
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,
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:
> *
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
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
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
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.)
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
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
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
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
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
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.
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 "bash history". And y
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
7;s good enough for POSIX, then it must be good
enough for bash, right?[1]
For a long time I was believing that ${X=Y} is just an obsolete and less
strict form of ${X:=Y} due to the way it is documented in BASH. Once I
needed to distinguish empty an unset values. First hits in search engine
r
On Wed, Jul 24, 2024 at 09:50:36AM -0400, Greg Wooledge wrote:
[...]
> Everyone skips over the sentence that begins with "Omitting the colon".
Thanks for this one. I know /I/ did for long enough.
Greg, this place would be a lot less helpful...
> Every time we try to tell Chet, "Hey, man, pleas
Hi,
i wrote:
> > maybe i am just too dumb to read the manual, or maybe i made an
> > archeological discovery in the shells we use.
Greg Wooledge wrote:
> Everyone skips over the sentence that begins with "Omitting the colon".
Oh well. Too dumb and not alone.
I did read the sentence immediately
On Wed, Jul 24, 2024 at 15:33:11 +0200, Thomas Schmitt wrote:
> GRUB's test scripts often show this gesture
>
> : "${TMPDIR=/tmp}"
>
> Well known and described is
> ${X:=Y}
> which assigns a default value to variable X if it is empty (man bash
> says:
Hi,
maybe i am just too dumb to read the manual, or maybe i made an
archeological discovery in the shells we use.
I came to a strange shell gesture which i find neither in man bash nor
man dash. Nevertheless it works the same in both shells.
GRUB's test scripts often show this ge
Hi,
thank you all for the fast response. It helped a lot and made everything
clear.
The problem is solved.
Have a nice eastern.
Best
Hans
On Thu, Mar 28, 2024 at 10:37:25AM +0100, Hans wrote:
> Hi folks,
>
> just an easy question:
>
> What is the difference (if any) between the following two variables in a
> shellfile in bash:
>
> 1. mypath=/home/user1/Tools/
Here you are assigning a value to the va
On Thu, Mar 28, 2024 at 10:37:25AM +0100, Hans wrote:
> What is the difference (if any) between the following two variables in a
> shellfile in bash:
>
> 1. mypath=/home/user1/Tools/
> 2. mypath="/home/user1/Tools/"
They are the same. The quotes are optional here
Hi folks,
just an easy question:
What is the difference (if any) between the following two variables in a
shellfile in bash:
1. mypath=/home/user1/Tools/
and $mypath
or
2. mypath="/home/user1/Tools/"
and $mypath
Is this in bash the same? Do other shells (sh, zsh, whatever) handle
On Tue, 5 Mar 2024 at 02:59, Greg Wooledge wrote:
We might *guess* that this change was made to make dash more strict
about POSIX minimalism (removing extensions), but without documentation
we can't do more than guess about motives.
The motivation is to avoid difference in behavior when compil
On Tue, 5 Mar 2024 at 02:59, Greg Wooledge wrote:
> On Tue, Mar 05, 2024 at 11:24:11AM +0900, John Crawley wrote:
> > ^ worked as a negator in dash character classes up to Bullseye though, so
> > something has changed recently. That's what my web searching failed to
> > find...
>
> It looks lik
On Tue, Mar 05, 2024 at 11:24:11AM +0900, John Crawley wrote:
> ^ worked as a negator in dash character classes up to Bullseye though, so
> something has changed recently. That's what my web searching failed to find...
It looks like dash doesn't have up-to-date documentation on its changes.
There
;s just not portable to sh.
Running shellcheck on a *sh* script with a [^s] glob gives
https://www.shellcheck.net/wiki/SC3026
"In POSIX sh, ^ in place of ! in glob bracket expressions is undefined."
with some links. There is no warning in the case of a #!/bin/bash script.
Thanks! Sh
shellcheck on a *sh* script with a [^s] glob gives
https://www.shellcheck.net/wiki/SC3026
"In POSIX sh, ^ in place of ! in glob bracket expressions is undefined."
with some links. There is no warning in the case of a #!/bin/bash script.
On 05/03/2024 11:02, Greg Wooledge wrote:
On Tue, Mar 05, 2024 at 10:49:34AM +0900, John Crawley wrote:
On 05/03/2024 05:27, David Wright wrote:
Which shell also matters. The OP appears to be using ^ to negate,
but ! has the advantage that it will be understood in bash and dash.
I think
On Tue, Mar 05, 2024 at 10:49:34AM +0900, John Crawley wrote:
> On 05/03/2024 05:27, David Wright wrote:
> > Which shell also matters. The OP appears to be using ^ to negate,
> > but ! has the advantage that it will be understood in bash and dash.
>
> I think ^ has been d
On 05/03/2024 05:27, David Wright wrote:
Pattern matching in the shell is not the same as in grep: the
rules are different, but similar enough to confuse.
Grep uses regular expressions, while the shell is usually globs. (I have no
experience of shells other than dash and bash though.)
Bash can
On Mon 04 Mar 2024 at 11:51:29 (+0900), John Crawley wrote:
> On 04/03/2024 10:07, David Wright wrote:
> > On Sun 03 Mar 2024 at 17:58:53 (-0600), Albretch Mueller wrote:
> > > bash doesn't seem to like dots too close to brackets:
> > >
&
On 04/03/2024 10:07, David Wright wrote:
On Sun 03 Mar 2024 at 17:58:53 (-0600), Albretch Mueller wrote:
bash doesn't seem to like dots too close to brackets:
echo "${_VAR//[^0-9a-zA-Z.,_-]/}"
works fine.
On 3/3/24, Albretch Mueller wrote:
_VAR="admissions.piedmo
On Sun 03 Mar 2024 at 17:58:53 (-0600), Albretch Mueller wrote:
> bash doesn't seem to like dots too close to brackets:
>
> echo "${_VAR//[^0-9a-zA-Z.,_-]/}"
>
> works fine.
>
> On 3/3/24, Albretch Mueller wrote:
> > _VAR="admissions.piedmont.e
bash doesn't seem to like dots too close to brackets:
echo "${_VAR//[^0-9a-zA-Z.,_-]/}"
works fine.
lbrtchx
On 3/3/24, Albretch Mueller wrote:
> _VAR="admissions.piedmont.edu_files?trackid=wnm:1980&PDFfiller=what-is-the-second-fundamental-theorem-of-calculus(1)
On Sun 31 Dec 2023 at 00:43:40 (-0600), Mike McClain wrote:
> I
> suspect logging into a system where you have no home for your primary
> user might get interesting.
That problem is simple to resolve. I have encrypted /home partitions
on all my systems, but the root filesystem has a /home/primaryU
Mr. Wooledge,
Long before I realized I could put /home/mike on a separate
partition I started putting my stuff on a separate partition and just
called it /mc. A couple of tomes I had different OS versions on the
same hard drive so it made sense to keep the portions of my stuff that
weren't OS s
1 - 100 of 4090 matches
Mail list logo
