On Wed, Jan 26, 2022 at 10:59:28PM -0600, David Wright wrote:
> On Mon 12 Apr 2021 at 11:26:49 (-0400), Greg Wooledge wrote:
> > On Mon, Apr 12, 2021 at 10:18:19AM -0500, David Wright wrote:
> > > I'm not using PS1 to test whether stdout is a terminal, but whether
> > > the file is running interact
On Mon 12 Apr 2021 at 11:26:49 (-0400), Greg Wooledge wrote:
> On Mon, Apr 12, 2021 at 10:18:19AM -0500, David Wright wrote:
> > I'm not using PS1 to test whether stdout is a terminal, but whether
> > the file is running interactively. From man bash:
> >
> > "PS1 is set and $- includes i if bash
On Mon 12 Apr 2021 at 11:26:49 (-0400), Greg Wooledge wrote:
> On Mon, Apr 12, 2021 at 10:18:19AM -0500, David Wright wrote:
> > I'm not using PS1 to test whether stdout is a terminal, but whether
> > the file is running interactively. From man bash:
> >
> > "PS1 is set and $- includes i if bash
On Mon, Apr 12, 2021 at 10:18:19AM -0500, David Wright wrote:
> I'm not using PS1 to test whether stdout is a terminal, but whether
> the file is running interactively. From man bash:
>
> "PS1 is set and $- includes i if bash is interactive, allowing a
> shell script or a startup file to test
On Sun 11 Apr 2021 at 10:45:22 (-0400), Greg Wooledge wrote:
> On Sun, Apr 11, 2021 at 09:10:24AM -0500, David Wright wrote:
> > For stdout, the problem is more serious. Every time you press TAB
> > expecting remote filename completion, you receive the profile output
> > from the other end, double-
On Sun 11 Apr 2021 at 10:41:31 (-0400), Greg Wooledge wrote:
> On Sun, Apr 11, 2021 at 09:11:47AM -0500, David Wright wrote:
> > On Sat 10 Apr 2021 at 15:21:57 (-0400), Greg Wooledge wrote:
> > > I'm not a fan of it, because I actually like to export PS1, rather
> > > than setting it in .bashrc eve
On Sun, Apr 11, 2021 at 05:00:23PM +, Lee wrote:
>
> really?!! What do you have in PS1?
>
PS1='\h:\w\$ '
> IMO, the if test needs an else and the directory name shouldn't be
> typed out multiple times -- it belongs in an e-var:
>
> dir="$HOME/AppImages"
> if [ -d "$dir" ] ; then
> PATH=
On 4/11/21, Greg Wooledge wrote:
> On Sun, Apr 11, 2021 at 09:11:47AM -0500, David Wright wrote:
>> On Sat 10 Apr 2021 at 15:21:57 (-0400), Greg Wooledge wrote:
>> > I'm not a fan of it, because I actually like to export PS1, rather
>> > than setting it in .bashrc every time. I may be in the mino
On Sun, Apr 11, 2021 at 09:10:24AM -0500, David Wright wrote:
> For stdout, the problem is more serious. Every time you press TAB
> expecting remote filename completion, you receive the profile output
> from the other end, double-escaped (so a forest of backslashes).
...? What the *hell* are you
On Sun, Apr 11, 2021 at 09:11:47AM -0500, David Wright wrote:
> On Sat 10 Apr 2021 at 15:21:57 (-0400), Greg Wooledge wrote:
> > I'm not a fan of it, because I actually like to export PS1, rather
> > than setting it in .bashrc every time. I may be in the minority there.
>
> Exported from .[bash_]
On Sat 10 Apr 2021 at 15:21:57 (-0400), Greg Wooledge wrote:
> On Sat, Apr 10, 2021 at 01:21:21PM -0500, David Wright wrote:
> > My start-up files, .bash_profile, .bashrc, and other files that
> > they source, contain permanent printf commands. When they finish
> > printing their output, the next t
On Sat 10 Apr 2021 at 18:59:21 (+), Lee wrote:
> On 4/10/21, David Wright wrote:
> > On Wed 07 Apr 2021 at 21:46:30 (+), Lee wrote:
> >> On 4/7/21, Marco Ippolito wrote:
> >> >> Where I want output, I protect it with:
> >> >>
> >> >> [ -n "$PS1" ] && printf …
> >> >
> >> > Maybe consi
On Sat, Apr 10, 2021 at 01:21:21PM -0500, David Wright wrote:
> My start-up files, .bash_profile, .bashrc, and other files that
> they source, contain permanent printf commands. When they finish
> printing their output, the next thing that's going to happen is
> that the shell will emit a prompt. S
On 4/10/21, David Wright wrote:
> On Wed 07 Apr 2021 at 21:46:30 (+), Lee wrote:
>> On 4/7/21, Marco Ippolito wrote:
>> >> Where I want output, I protect it with:
>> >>
>> >> [ -n "$PS1" ] && printf …
>> >
>> > Maybe consider:
>> >
>> >[[ -t 1 ]] && printf ...
>>
>> Until your script
On Wed 07 Apr 2021 at 21:46:30 (+), Lee wrote:
> On 4/7/21, Marco Ippolito wrote:
> >> Where I want output, I protect it with:
> >>
> >> [ -n "$PS1" ] && printf …
> >
> > Maybe consider:
> >
> > [[ -t 1 ]] && printf ...
>
> Until your script that was started via crontab silently fails
> >> Where I want output, I protect it with:
> >>
> >> [ -n "$PS1" ] && printf …
> >
> > Maybe consider:
> >
> > [[ -t 1 ]] && printf ...
>
> Until your script that was started via crontab silently fails. I
> *like* always having error messages enabled.
I like logs too but -t was in the
On Thu, Apr 08, 2021 at 07:50:23AM +, Curt wrote:
> What about addressing his primary point rather than what in my
> benefit-of-the-doubt humor I construe as a typographical oversight?
I don't remember what the "primary point" was. Was it the same as
the Subject: header -- .profile not being
On Thu, Apr 08, 2021 at 11:14:48AM +0100, Tixy wrote:
> I believe ">/dev/stderr" is not Posix standard and knowing the correct
> standard way of doing this could be beneficial.
That's correct -- it's not portable.
On systems where /dev/stderr actually exists (such as Debian GNU/Linux),
according
On Thu, 2021-04-08 at 07:50 +, Curt wrote:
> On 2021-04-07, Greg Wooledge wrote:
> > On Wed, Apr 07, 2021 at 09:41:51PM +, Lee wrote:
> > > Interesting.. "echo foo" in .bashrc does break scp, but not "echo foo >2"
> >
> > That redirects to a file named "2".
> >
> > > .. but that doesn't
On 2021-04-07, Greg Wooledge wrote:
> On Wed, Apr 07, 2021 at 09:41:51PM +, Lee wrote:
>> Interesting.. "echo foo" in .bashrc does break scp, but not "echo foo >2"
>
> That redirects to a file named "2".
>
>> .. but that doesn't work for bash, so hhrmm.. > /dev/stderr seems to
>> work in all
On Wed, Apr 07, 2021 at 09:41:51PM +, Lee wrote:
> Interesting.. "echo foo" in .bashrc does break scp, but not "echo foo >2"
That redirects to a file named "2".
> .. but that doesn't work for bash, so hhrmm.. > /dev/stderr seems to
> work in all cases:
You wanted >&2 .
On 4/7/21, Marco Ippolito wrote:
>> Where I want output, I protect it with:
>>
>> [ -n "$PS1" ] && printf …
>
> Maybe consider:
>
> [[ -t 1 ]] && printf ...
Until your script that was started via crontab silently fails. I
*like* always having error messages enabled.
Lee
On 4/7/21, Greg Wooledge wrote:
> On Wed, Apr 07, 2021 at 03:16:41PM +, Lee wrote:
>> On 4/7/21, Gene Heskett wrote:
<.. snip ..>
>> > Any idea why its not working?
>>
>> A typo in your script? Add an else clause that shows the error and
>> that will probably show you what's wrong -- eg
>>
> Where I want output, I protect it with:
>
> [ -n "$PS1" ] && printf …
Maybe consider:
[[ -t 1 ]] && printf ...
On Wed 07 Apr 2021 at 11:33:02 (-0400), Greg Wooledge wrote:
> On Wed, Apr 07, 2021 at 03:16:41PM +, Lee wrote:
> > A typo in your script? Add an else clause that shows the error and
> > that will probably show you what's wrong -- eg
> >
> > dir="$HOME/AppImages"
> > if [ -d "$dir" ] ; then
>
On Wednesday 07 April 2021 08:28:49 IL Ka wrote:
> > The first of them will be added but not the other if I
> > . .profile
>
> Try to debug it. First of all, run this from the command line:
>
> [ -d "$HOME/AppImages" ] ; echo $?
>
> result should be "0". If not, then there must be some problem wi
On Wed, Apr 07, 2021 at 03:16:41PM +, Lee wrote:
> On 4/7/21, Gene Heskett wrote:
> > Greetings all;
> >
> > I just installed buster on a Dell 7010 and I have added two stanza's to
> > my .profile, to find a logout and back in does not establish a new
> > $PATH.
>
> Probably because you've go
On Wednesday 07 April 2021 08:28:49 IL Ka wrote:
> > The first of them will be added but not the other if I
> > . .profile
>
> Try to debug it. First of all, run this from the command line:
>
> [ -d "$HOME/AppImages" ] ; echo $?
>
> result should be "0". If not, then there must be some problem wi
On 4/7/21, Gene Heskett wrote:
> Greetings all;
>
> I just installed buster on a Dell 7010 and I have added two stanza's to
> my .profile, to find a logout and back in does not establish a new
> $PATH.
Probably because you've got a window manager that does the login stuph for you..
> The first o
On Wed 07 Apr 2021 at 08:16:43 (-0400), Gene Heskett wrote:
>
> I just installed buster on a Dell 7010 and I have added two stanza's to
> my .profile, to find a logout and back in does not establish a new
> $PATH.
>
> The first of them will be added but not the other if I
> . .profile
>
> The
On Wed, Apr 07, 2021 at 08:16:43AM -0400, Gene Heskett wrote:
> I just installed buster on a Dell 7010 and I have added two stanza's to
> my .profile, to find a logout and back in does not establish a new
> $PATH.
> Any idea why its not working?
How do you log in? Probably with a GUI, yes?
ht
>
>
> The first of them will be added but not the other if I
> . .profile
>
Try to debug it. First of all, run this from the command line:
[ -d "$HOME/AppImages" ] ; echo $?
result should be "0". If not, then there must be some problem with this
directory (check name, case, etc).
Then try
set
Greetings all;
I just installed buster on a Dell 7010 and I have added two stanza's to
my .profile, to find a logout and back in does not establish a new
$PATH.
The first of them will be added but not the other if I
. .profile
The additions to .profile are:
=
# set PATH so it includes user
33 matches
Mail list logo
