On Thu, Aug 05, 2021 at 07:19:11AM -0400, Greg Wooledge wrote:
> On Thu, Aug 05, 2021 at 10:07:12AM +0200, to...@tuxteam.de wrote:
> > [1] Nowadays this is a little white lie: most shells have them
> >as builtins, but they are supposed to behave like regular
> >programs, for compat. There /
ich is spelled with a hyphen and
then some letter (-e or -d or -x, etc.).
If the first argument isn't either of those, the result is "unspecified".
It will probably be an error, unless your shell overrides it for some
reason.
unicorn:~$ test one two
bash: test: one: unary operator ex
On Thu, Aug 05, 2021 at 10:07:12AM +0200, to...@tuxteam.de wrote:
> [1] Nowadays this is a little white lie: most shells have them
>as builtins, but they are supposed to behave like regular
>programs, for compat. There /is/ a /bin/test, but I can't
>find a /bin/[ on my system anymore.
On Thu, Aug 05, 2021 at 09:26:35AM +0100, Tixy wrote:
> On Thu, 2021-08-05 at 10:36 +0300, Anssi Saari wrote:
> [...]
> >
> > [ A="0 ; " ]
> >
> > is always true. It seems it probably has something to do with expansion,
> > quoting and the special meaning of ;.
> >
>
> ; has no special meaning
On Thu, 2021-08-05 at 10:36 +0300, Anssi Saari wrote:
[...]
>
> [ A="0 ; " ]
>
> is always true. It seems it probably has something to do with expansion,
> quoting and the special meaning of ;.
>
; has no special meaning inside "". The expression is true because
there is only a single non-null
above. Imagine what happens if you lose
the quotes around "$A":
if test $A = "0 ; "
now transforms to
if test 0 ; = "0 ; "
Now test sees *four* arguments: "0", ";", "=" and "0 ; ". this
confuses the h
"Gary L. Roach" writes:
> Hi all;
>
> I have just recently delved into the magical world of Bash scripting
> and programmed up the following script(not finished). The object is to
> parse the Path and check for the existence of each directory. Please
> don't
On 8/5/2021 5:47 AM, Gary L. Roach wrote:
Thanks for the help but I still have the problem of the if statement
always being true. This time I enclosed the file so you can test it.
Two things:
- Why is the var 'IFS' set above the read command?
- What are you trying to do here?
--
John Doe
Thanks for the help but I still have the problem of the if statement
always being true. This time I enclosed the file so you can test it.
Gary R
On 8/4/21 5:04 PM, Greg Wooledge wrote:
On Wed, Aug 04, 2021 at 04:58:00PM -0700, Gary L. Roach wrote:
Path="/Test/gary/run/something"
IFS=/
read -a
On Wed, Aug 04, 2021 at 04:58:00PM -0700, Gary L. Roach wrote:
> Path="/Test/gary/run/something"
> IFS=/
> read -a Array <<< $Path
You're setting IFS permanently for the whole script. It's usually better
to set it only for the duration of the single read command which uses
it. Also, read should
Hi all;
I have just recently delved into the magical world of Bash scripting and
programmed up the following script(not finished). The object is to parse
the Path and check for the existence of each directory. Please don't
send back an Awk or Sed statement that is more efficient. I am h
* 2021-07-30 07:41:23-0400, Greg Wooledge wrote:
> On Fri, Jul 30, 2021 at 08:48:28AM +0300, Teemu Likonen wrote:
>> You have already got answers but here is another. Bash has a special
>> arithmetic evaluation mode which happens in:
>>
>> let ... # r
On Fri, Jul 30, 2021 at 08:48:28AM +0300, Teemu Likonen wrote:
> scanimage > /home/mick/DATA/SCANS/scan-$((++ct)).pnm
Correct, but not necessarily an improvement over the original code.
It depends on your taste for complexity.
> You have already got answers but here is another. B
ckets and not having
> the "$" ?
You have already got answers but here is another. Bash has a special
arithmetic evaluation mode which happens in:
let ... # returns true (0) or false (1)
(( ... ))# returns true (0) or false (1)
$(( ... )) # re
On Thu, Jul 29, 2021 at 07:38:07PM -0400, kamaraju kusumanchi wrote:
> On Thu, Jul 29, 2021 at 4:23 PM Greg Wooledge wrote:
> >
> > On Thu, Jul 29, 2021 at 09:16:26PM +0100, mick crane wrote:
> > > 4 ((ct++))
> >
> > > What's the thing with the ct being in double brackets and not having the
> >
On Thu, Jul 29, 2021 at 4:23 PM Greg Wooledge wrote:
>
> On Thu, Jul 29, 2021 at 09:16:26PM +0100, mick crane wrote:
> > 4 ((ct++))
>
> > What's the thing with the ct being in double brackets and not having the "$"
> > ?
>
> https://mywiki.wooledge.org/ArithmeticExpression
>
Nice wiki page, Gre
Am 29. Jul, 2021 schwätzte mick crane so:
moin moin nick,
I nicked this off some guy on the internet.
1 #!/bin/bash
2 count_file="scan_count.txt"
3 ct=`cat $count_file`
4 ((ct++))
5 scanimage > /home/mick/DATA/SCANS/scan-$ct.pnm
6 echo $ct > $count_file
What's
On Thu, Jul 29, 2021 at 09:16:26PM +0100, mick crane wrote:
> 4 ((ct++))
> What's the thing with the ct being in double brackets and not having the "$"
> ?
https://mywiki.wooledge.org/ArithmeticExpression
I nicked this off some guy on the internet.
1 #!/bin/bash
2 count_file="scan_count.txt"
3 ct=`cat $count_file`
4 ((ct++))
5 scanimage > /home/mick/DATA/SCANS/scan-$ct.pnm
6 echo $ct > $count_file
What's the thing with the ct being in double bracke
On Fri, 9 Jul 2021 16:53:45 -0400
Greg Wooledge wrote:
> Since it's a function, and not a script, there's no shebang. So I'm
> guessing shellcheck assumed it was /bin/sh code, rather than bash
> code. <<< is just one of the bashisms I used here. local is
&
e substring
match, you can just use [[ $PATH != *substring* ]]
But as I said in a different message, if you're going down this road
(which is more typical for sh than for bash), you will want to delimit
both the left-hand and right-hand sides with extra : characters.
Without those, you will get fal
st for the existence of the given path.
I can write expressions that work to detect the given path in $PATH.
What I don't seem able to do is combine all that in a script.
Here's what I have for the script:
#!/bin/bash
# A short script for testing some code.
# pelican seems to like loca
in the "IFS=: read" line,
> but I'm not going to worry about that.
Since it's a function, and not a script, there's no shebang. So I'm
guessing shellcheck assumed it was /bin/sh code, rather than bash code.
<<< is just one of the bashisms I used here. l
On Fri, 9 Jul 2021 16:25:11 -0400
Greg Wooledge wrote:
> add_path_maybe() {
> local p i
> ...
Very nice, sir. Thank you.
shellcheck complained about the redirection in the "IFS=: read" line,
but I'm not going to worry about that.
--
Does anybody read signatures any more?
https://charlescu
On Fri, 9 Jul 2021 22:11:05 +0200
Joerg Kampmann wrote:
> > I call the script with the . operator: ". test.sh"
> this is the result:
>
>
> root@primergy:~/software-env# . test.sh
>
> Substr is /root/.local/bin/
> Substring NOT found.
> root@primergy:~/software-env#
OK, that's what I get if
I am sorry I found myself in the wrong thread ... so discard
Am 09.07.21 um 22:25 schrieb Greg Wooledge:
On Fri, Jul 09, 2021 at 01:54:19PM -0600, Charles Curley wrote:
I'd like to check two things:
* Whether a given path is not already in the $PATH variable
* Whether the given path already e
On Fri, Jul 09, 2021 at 01:54:19PM -0600, Charles Curley wrote:
> I'd like to check two things:
>
> * Whether a given path is not already in the $PATH variable
>
> * Whether the given path already exists
>
> If both are true, I'd like to add the given path to the $PATH variable.
add_path_maybe(
st for the existence of the given path.
I can write expressions that work to detect the given path in $PATH.
What I don't seem able to do is combine all that in a script.
Here's what I have for the script:
#!/bin/bash
# A short script for testing some code.
# pelican seems to like loca
can write expressions that work to detect the given path in $PATH.
What I don't seem able to do is combine all that in a script.
Here's what I have for the script:
#!/bin/bash
# A short script for testing some code.
# pelican seems to like local installations here.
SUBSTR="${HOME}&quo
davidson wrote:
> >
> > I actually looked with `hd` and expected to see 0x20 there, but
> > somehow see none of it:
> >
> > $ echo $COMP_WORDBREAKS | hd
> > 22 27 40 3e 3c 3d 3b 7c 26 28 3a 0a |"'@><=;|&(:.|
> > 000c
>
> Above I count 12 characters piped from echo to
On 2021-04-26 02:43 PM, Steve Dondley wrote:
I downloaded and ran this docker image: https://hub.docker.com/_/debian
It works, but typically when I hit the ctrl-p key at the bash prompt,
it acts like the up arrow key and shows the previous command.
However, I have to hit ctrl-p twice to show
On Mon 26 Apr 2021 at 18:27:57 (+), davidson wrote:
> On Mon, 26 Apr 2021 davidson wrote:
>
> Two corrections to previous message.
> > % Proposal D
> >
> > $ cat ~/.inputrc # a literal Shift-TAB is inside the double quotes
> > " ": menu-complete
>
> 2. The '^[' above is an artifact of...
I downloaded and ran this docker image: https://hub.docker.com/_/debian
It works, but typically when I hit the ctrl-p key at the bash prompt, it
acts like the up arrow key and shows the previous command.
However, I have to hit ctrl-p twice to show the previous command and
twice each time to
On Mon, 26 Apr 2021 davidson wrote:
Two corrections to previous message.
[dd]
% Proposal C
In that case, you could get all but the last argument completed like
so:
$ complete -A hostname -P '-h ' -S ' -s'
1. At the end of the line above, the command name is missing.
$ complete -A hostnam
ike they are in your example?
If so, you can do this:
$ complete -P "-h test" -W "'1 -s foo' '2 -s bar'" app3
At bash prompt, type "app3 1", then hit TAB, and you'll get
$ app3 -h test1 -s foo
Or type "app3 2", then hit TAB, and y
have the same name as printf(3).)
There are a few changes between printf(3) and printf(1), and a few
more bash extensions added to bash's builtin implementation.
The big change here is that if you supply more arguments than there
are format specifiers, printf(1) implicitly loops, and reuses th
Hi,
Greg Wooledge wrote:
> Not the parser, technically. The correct term is word splitting.
Always good to know which part of the shell tries to bite me. :))
> $ string=' hithere '
> [...]
> $ printf '<%s> ' $string ; echo
>
As C programmer i am now tempted to scream.
(This command
On Mon, Apr 26, 2021 at 12:04:45PM +0200, Thomas Schmitt wrote:
> > what accounts for the three missing characters (namely SPACE, TAB,
> > and NEWLINE)?
>
> They get eaten by the shell parser if you do not use quotation marks:
>
> $ echo $COMP_WORDBREAKS | wc -c
> 11
> $ echo "$COMP_WORDBRE
Hi,
> what accounts for the three missing characters (namely SPACE, TAB,
> and NEWLINE)?
They get eaten by the shell parser if you do not use quotation marks:
$ echo $COMP_WORDBREAKS | wc -c
11
$ echo "$COMP_WORDBREAKS" | wc -c
14
So to see all characters (including the newline added by
expect you will see
that they are the first three characters of the content of
COMP_WORDBREAKS.
$ echo "$COMP_WORDBREAKS" | hd
20 09 0a 22 27 40 3e 3c 3d 3b 7c 26 28 3a 0a | .."'@><=;|&(:.|
000f
For more explanation, see
bash(1), section EXPANS
; > (if someone cares to provide it) would help me understand the idea, and
> > I could use it in a dynamic completion later if I need to.
> >
> > > You could always generate
> > > lists of aliases dynamically, too.
> >
> > Well, I can make bash regene
it's trying to split on
> > > > > > spaces (here I press several times:
> > > > > >
> > > > > > [vas@test2 ~]$ app3 -h -h -h test
> > > > > >
> > > > > > Can you please give a hint how to make it com
t; > > "-h test1 -s foo" or "-h test2 -s bar" as a whole?
> > > > >
> > > > > I would not like to make all this too complicated, write complex
> > > > > completion funcions if possible. A static (-W) completion would be
&g
perhaps one of the other 20-odd categories
recognised by the -A option for bash builtin "complete"?
I would not like to make all this too complicated, write complex
completion funcions if possible.
In the case you describe, you might find the behaviour of readline
function &quo
> Can you please give a hint how to make it complete "app3" with either
> > > > "-h test1 -s foo" or "-h test2 -s bar" as a whole?
> > > >
> > > > I would not like to make all this too complicated, write complex
> > > > compl
; > > Can you please give a hint how to make it complete "app3" with either
> > > "-h test1 -s foo" or "-h test2 -s bar" as a whole?
> > >
> > > I would not like to make all this too complicated, write complex
> > > completion
t; I would not like to make all this too complicated, write complex
> > completion funcions if possible. A static (-W) completion would be even
> > better.
>
> Perhaps:
>
> alias app3a='app3 -h test1 -s foo'
> alias app3b='app3 -h test2 -s bar'
No, not alias, I'd like to do it via bash completion. I may want to make
it dynamic eventually, the problem is in the spaces.
--
Victor Sudakov VAS4-RIPE
http://vas.tomsk.ru/
2:5005/49@fidonet
signature.asc
Description: PGP signature
On Thu 22 Apr 2021 at 15:28:36 (+0700), Victor Sudakov wrote:
>
> I have an example app which can be run only as "app3 -h test1 -s foo" or
> "app3 -h test2 -s bar". So I decided to provide it with a small manual
> completion for convenience.
>
> [vas@test2 ~]$ ./list.sh
> -h test1 -s foo
> -h te
Dear Colleagues,
I have an example app which can be run only as "app3 -h test1 -s foo" or
"app3 -h test2 -s bar". So I decided to provide it with a small manual
completion for convenience.
[vas@test2 ~]$ ./list.sh
-h test1 -s foo
-h test2 -s bar
[vas@test2 ~]$ complete -C ./list.sh app3
[vas@tes
On Ma, 22 sep 20, 16:37:40, Gary Dale wrote:
>
> Your first point makes it impossible for me to present anything because this
> list doesn't (AFAIK) allow attachments.
This is a myth, I just attached a small script to this message.
The list apparently does indeed filter some attachments most lik
at is only available in bash
(can't recall a case of that). Moreover, the consensus seems to be that
if there was an error on the shebang line, the default shell would be used.
The smallest complete script then is
report=”/root/clamscan-report”
echo $report
but as I explained, that works on one
On Tue, Sep 22, 2020 at 04:37:40PM -0400, Gary Dale wrote:
> The smallest complete script then is
>
> report=”/root/clamscan-report”
> echo $report
There are three errors in this script.
1) There is no shebang line.
2) You've got curly quotes instead of ASCII double-quotes.
3) You used a variabl
On Lu, 21 sep 20, 17:22:26, Gary Dale wrote:
>
> I presented the line that failed, copied and pasted from the Konsole
> session. What more do you want, other than to complain?
In such cases it is best to attach[1] the smallest complete[2] script
demonstrating the behaviour.
Based on the informa
) I don't see any 'compat' keywords... (?)
Correct.
STFW https://html.duckduckgo.com/html?q=dash%20compat42 I don't see 'compat'
anywhere on the first page of hits... (?)
Where are the above settings documented?
In bash(1). They are bash settings.
To the best of
't see any 'compat' keywords... (?)
Correct.
> STFW https://html.duckduckgo.com/html?q=dash%20compat42 I don't see 'compat'
> anywhere on the first page of hits... (?)
>
> Where are the above settings documented?
In bash(1). They are bash settings.
To
On 2020-09-21 00:52, to...@tuxteam.de wrote:
On Sun, Sep 20, 2020 at 05:27:49PM -0400, Gary Dale wrote:
Where does this behaviour (keeping the quotes) get set?
What does the builtin "shopt" say? Especially the value of `compat42'
is involved in quote removal.
Joy! Joy! Happy! Happy! Anoth
On Sun, Sep 20, 2020 at 05:27:49PM -0400, Gary Dale wrote:
> I have the same bash script on two different Debian/Buster AMD64
> servers. However on one it refused to run. I tracked it down quickly
> to a variable substitution problem.
>
> The line causing the problem reads: report=
On 2020-09-20 18:14, The Wanderer wrote:
On 2020-09-20 at 17:27, Gary Dale wrote:
I have the same bash script on two different Debian/Buster AMD64
servers. However on one it refused to run. I tracked it down quickly
to a variable substitution problem.
The line causing the problem reads
I have the same bash script on two different Debian/Buster AMD64
servers. However on one it refused to run. I tracked it down quickly to
a variable substitution problem.
The line causing the problem reads: report="/root/clamscan-report"
On one server echo $report prints /roo
On 2020-09-20 15:14, The Wanderer wrote:
On 2020-09-20 at 17:27, Gary Dale wrote:
I have the same bash script on two different Debian/Buster AMD64
servers. However on one it refused to run. I tracked it down quickly
to a variable substitution problem.
The line causing the problem reads
On 2020-09-20 at 17:27, Gary Dale wrote:
> I have the same bash script on two different Debian/Buster AMD64
> servers. However on one it refused to run. I tracked it down quickly
> to a variable substitution problem.
>
> The line causing the problem reads: report="/root/clam
mething, and backspacing doesn't word wrap back to the previously
> typed line.
If characters are typed by a process while you're typing a command
line, then naively trying to backspace over a newline will not work
because bash has a different idea of where the cursor is from reality.
wrote:
> On Mon, Aug 03, 2020 at 12:47:32AM -0400, songbird wrote:
>> ...
>>=20
>> i'm not familiar with that problem but another tip
>> which is helpful when dealing with a terminal that
>> gets into a strange state is to press return then
>> type in reset and press return again.
>
> Typing ret
ck to the previously
typed line.
Had trouble sleeping =) trying to figure it out.
I don't know if it's Bash related, inputrc, terminal, debian, or whatever.
I was reading that perhaps setting the "auto left margin" to ON, would
allow the cursor to wordwrap (in reverse) to t
On Mon, Aug 03, 2020 at 12:47:32AM -0400, songbird wrote:
> ...
>
> i'm not familiar with that problem but another tip
> which is helpful when dealing with a terminal that
> gets into a strange state is to press return then
> type in reset and press return again.
Typing return when you have alr
...
i'm not familiar with that problem but another tip
which is helpful when dealing with a terminal that
gets into a strange state is to press return then
type in reset and press return again.
songbird
On Sun 02 Aug 2020 at 17:34:07 (+0200), Esteban L wrote:
>
> I use terminal window/bash quite a bit, and have a quirky behavior on
> Debian, at least not on Mac OS terminal window. I think it's just a
> default issue, that can be altered -- as I had the exact same problem
>
Thanks for the tip Andrei!
I am not 100% sure it was .bashrc, it could have been some other config
file, but I am pretty sure it was bash related. it is unfortunately on a
long since gone system.
As to my current system, I have just default settings. I have not
altered anything. I have only
On Du, 02 aug 20, 17:34:07, Esteban L wrote:
>
> Last time I had this issue, I remember I had to go into .bashrc and
> add/change something. I just don't know what it was.
Could it be you changed .inputrc and not .bashrc?
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
signa
, I did solve this at one point in the past, with a bash profile
change, so I know that is possible.
On 02.08.20 17:49, The Wanderer wrote:
> On 2020-08-02 at 11:34, Esteban L wrote:
>
>> Hello,
>>
>> I use terminal window/bash quite a bit, and have a quirky behavior
>&
On Sun, Aug 02, 2020 at 05:34:07PM +0200, Esteban L wrote:
> Hello,
[...]
> Maybe best description is:
>
> I am tying this senten
>
>
>
> ce, and it's fine...but i
>
>
>
> I backspace now, as I want to replace the above line "and it's fine" and
> what comes after it to change it to "it's n
On 2020-08-02 at 11:34, Esteban L wrote:
> Hello,
>
> I use terminal window/bash quite a bit, and have a quirky behavior
> on Debian, at least not on Mac OS terminal window. I think it's just
> a default issue, that can be altered -- as I had the exact same
> problem years
Hello,
I use terminal window/bash quite a bit, and have a quirky behavior on
Debian, at least not on Mac OS terminal window. I think it's just a
default issue, that can be altered -- as I had the exact same problem
years ago -- that I was able to resolve, which I again turns up. I
forgo
* On 2020 08 Jul 08:38 -0500, Greg Wooledge wrote:
> There are lots of choices here. And this is with only the login shell
> layer involved -- no X11 or Wayland.
Good points and it must be emphasized that ~/.profile or ~/.bash_profile
are for *login* shells only. Ordinarily shells started from a
session, because that sure as hell is
false for X11 sessions.
> There is a caveat! Isn't there always? The comments at the top of
> /etc/skel/.profile note:
>
> # ~/.profile: executed by the command interpreter for login shells.
> # This file is not read by bash(1), if
this file (I've not tried it yet
myself).
There is a caveat! Isn't there always? The comments at the top of
/etc/skel/.profile note:
# ~/.profile: executed by the command interpreter for login shells.
# This file is not read by bash(1), if ~/.bash_profile or ~/.bash_login
# exists.
#
ved. Assuming you're logging in with a "Debian
> X session", a POSIX shell (sh) is used to read most of the config files
> for the Xsession stuff. Bash extensions like exporting functions won't
> be possible at that point.
>
> > - so launch startx, figur
(sh) is used to read most of the config files
for the Xsession stuff. Bash extensions like exporting functions won't
be possible at that point.
> - so launch startx, figuring out over many failures to start "modern"
> "sessions"
Yeah, as I keep saying to others on th
On Mi, 08 iul 20, 10:44:39, Zenaan Harkness wrote:
>
> - so try somewhere in the session startup apps - nope, courdn't
> figure it out at least
For Debian you want ~/.xsessionrc
Kind regards,
Andrei
--
http://wiki.debian.org/FAQsFromDebianUser
signature.asc
Description: PGP signature
On Mi, 08 iul 20, 09:59:52, Zenaan Harkness wrote:
> On Tue, Jul 07, 2020 at 10:29:47AM -0400, Greg Wooledge wrote:
> >
> > $HOME/bin is placed into the user's default PATH by Debian's ~/.profile
> > (the one in /etc/skel/.profile) if it exists at the time the ~/.profile
> > is read, if the ~/.pro
a non-interactive shell to read ~/.profile (along with other
> configuration files).
Some of us use ~/.bash_profile (and even ~/.bash_login) which will
override ~/.profile being read. Of course, you're best reading
man bashfor a fuller story of bash's machinations.
Cheers,
David.
ehensive overveiw of every possible piece
> of every possible configuration, but it's a starting point.
I faced this issue a few years back, doing a Linux console login (manual crypt
bindmount for $HOME), setting some env functions in BASH, and very naievely
thinking they would ap
On Wed, Jul 08, 2020 at 09:59:52AM +1000, Zenaan Harkness wrote:
> On Tue, Jul 07, 2020 at 10:29:47AM -0400, Greg Wooledge wrote:
> > On Tue, Jul 07, 2020 at 03:17:37PM +0100, Jonathan Dowland wrote:
> > > On Tue, Jul 07, 2020 at 04:14:16PM +0200, Nicolas George wrote:
> > > > cd ~/bin
> > > > ln -
Ahh, asked too soon. Thanks Greg.
On Tue, Jul 07, 2020 at 10:16:21AM -0400, Greg Wooledge wrote:
> On Tue, Jul 07, 2020 at 09:57:34AM -0400, Stephen P. Molnar wrote:
> > The Subject line is the problem
>
> Yeah. The Subject: line reveals the problem: you believe that PATH is
> set primarily by
On Tue, Jul 07, 2020 at 10:29:47AM -0400, Greg Wooledge wrote:
> On Tue, Jul 07, 2020 at 03:17:37PM +0100, Jonathan Dowland wrote:
> > On Tue, Jul 07, 2020 at 04:14:16PM +0200, Nicolas George wrote:
> > > cd ~/bin
> > > ln -s ../opt/something/bin/something
> >
> > Not in the default PATH either.
>
Jonathan Dowland (12020-07-07):
> Not in the default PATH either.
No, but probably one of the first things anybody who has non-elementary
use will have configured anyway.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
On Tue, Jul 07, 2020 at 03:17:37PM +0100, Jonathan Dowland wrote:
> On Tue, Jul 07, 2020 at 04:14:16PM +0200, Nicolas George wrote:
> > cd ~/bin
> > ln -s ../opt/something/bin/something
>
> Not in the default PATH either.
$HOME/bin is placed into the user's default PATH by Debian's ~/.profile
(th
On Tue, Jul 07, 2020 at 04:14:16PM +0200, Nicolas George wrote:
cd ~/bin
ln -s ../opt/something/bin/something
Not in the default PATH either.
--
👱🏻 Jonathan Dowland
✎j...@debian.org
🔗 https://jmtd.net
On Tue, Jul 07, 2020 at 09:57:34AM -0400, Stephen P. Molnar wrote:
> The Subject line is the problem
Yeah. The Subject: line reveals the problem: you believe that PATH is
set primarily by your shell.
It's not. It's set primarily by your method of login, and then by your
session tools, whether t
Roberto C. Sánchez (12020-07-07):
> You should add the export command to ~/.bashrc (for it to only be in
> effect for that user)
Except ~/.bashrc is only sourced for interactive shells, it will not be
run when applications are executed by a GUI, for example.
(Also, for some reason, th
On Tue, Jul 07, 2020 at 09:57:34AM -0400, Stephen P. Molnar wrote:
> The Subject line is the problem with my Debian Buster platform. Now from
> Google I see that there has been a change in the way Debian handles this
> problem.
>
I'm not sure what change you are referring to, but from what you
des
The Subject line is the problem with my Debian Buster platform. Now from
Google I see that there has been a change in the way Debian handles this
problem.
My user path statement is:
comp@AbNormal:~$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
Now I have a number of app
On Sat 20 Jun 2020 at 16:51:12 -0600, Tom Dial wrote:
>
>
> On 6/20/20 13:17, Andrei POPESCU wrote:
>
> > On Sb, 20 iun 20, 18:37:31, Brian wrote:
> >> On Sat 20 Jun 2020 at 17:53:56 +0300, Andrei POPESCU wrote:
> >>
> >>> On Vi, 19 iun 20, 15:12:27, Tom Dial wrote:
>
> I notice that
On 6/20/20 13:17, Andrei POPESCU wrote:
> On Sb, 20 iun 20, 18:37:31, Brian wrote:
>> On Sat 20 Jun 2020 at 17:53:56 +0300, Andrei POPESCU wrote:
>>
>>> On Vi, 19 iun 20, 15:12:27, Tom Dial wrote:
I notice that tasksel (= /usr/bin/tasksel) is a Perl program in which it
appears th
On Sb, 20 iun 20, 18:37:31, Brian wrote:
> On Sat 20 Jun 2020 at 17:53:56 +0300, Andrei POPESCU wrote:
>
> > On Vi, 19 iun 20, 15:12:27, Tom Dial wrote:
> > >
> > > I notice that tasksel (= /usr/bin/tasksel) is a Perl program in which it
> > > appears the "cmd" to be executed once selections are
On Sat 20 Jun 2020 at 17:53:56 +0300, Andrei POPESCU wrote:
> On Vi, 19 iun 20, 15:12:27, Tom Dial wrote:
> >
> > I notice that tasksel (= /usr/bin/tasksel) is a Perl program in which it
> > appears the "cmd" to be executed once selections are made (line 24 from
> > the end) is
> >
> > apt-get -
On Vi, 19 iun 20, 09:30:30, David Wright wrote:
>
> One other benefit: the knowledge and skills you gain in this process
> will be far more transferable than a deeper understanding of the d-i.
> After all, I haven't gained the impression that you're in technical
> charge of rolling out, say, 5000
On Vi, 19 iun 20, 15:12:27, Tom Dial wrote:
>
> I notice that tasksel (= /usr/bin/tasksel) is a Perl program in which it
> appears the "cmd" to be executed once selections are made (line 24 from
> the end) is
>
> apt-get -q -y -o APT::Install-Recommends=true -o \
> APT::Get::AutomaticRemove=true
On Fri 19 Jun 2020 at 15:12:27 -0600, Tom Dial wrote:
> I notice that tasksel (= /usr/bin/tasksel) is a Perl program in which it
> appears the "cmd" to be executed once selections are made (line 24 from
> the end) is
>
> apt-get -q -y -o APT::Install-Recommends=true -o \
> APT::Get::AutomaticRemo
On 19.06.20 23:12, Tom Dial wrote:
On 6/19/20 09:28, Brian wrote:
On Thu 18 Jun 2020 at 14:15:00 -0500, David Wright wrote:
On Wed 17 Jun 2020 at 20:48:50 (+0100), Brian wrote:
AFAICT, it appears Recommends are *always* installed using the Installer,
irrespective of preseeding. Not *someti
301 - 400 of 4071 matches
Mail list logo
