On Fri, Jan 26, 2024 at 03:28:11PM +0200, Ricky Tigg wrote:
> $ export EDITOR='/usr/bin/nano' && source $HOME/.bashrc
> $ echo $EDITOR
> /usr/bin/vim
>
> Expected: Latest command's output to be "/usr/bin/nano" instaed of
> "/usr/bin/vim".
It's really unclear to me why you expected this. You're c
On 1/26/24 8:28 AM, Ricky Tigg wrote:
Hopefully, my interpretation of the 'source' command is correct.
It's not: the `source' command reads and executes commands from the
filename argument. What do you think it does, and why do you think
the results you expected are correct?
--
``The lyf so s
On Fri, Jan 26, 2024, 14:29 Ricky Tigg wrote:
> BASH version: 5.2.26(1)-release. OS: Fedora; Desktop edition.
>
> Hello.
>
> Current state: Vim set as default text editor.
>
> $ cat .bashrc | grep '^export EDITOR'
> export EDITOR='/usr/bin/vim'
> $ typeset -p EDITOR
> declare -x EDITOR="/usr/bin/
Hi Greg,
The links you pointed me are great. They were exactly what I was looking
for. Thanks a lot.:-)
j
On 03/27/2014 06:32 PM, Greg Wooledge wrote:
On Thu, Mar 27, 2014 at 08:19:39AM -0700, esoj wrote:
I need to specify a variable path after #! but seems to me that bash can't
do this.
For
On Thu, Mar 27, 2014 at 08:19:39AM -0700, esoj wrote:
> I need to specify a variable path after #! but seems to me that bash can't
> do this.
> For example I need to specify the $HOME or ~ path as in:
>
>
> #!~/bin/python
> or
> #!$HOME/bin/python
This belongs on help-bash, not bug-bash. That s
On 4/19/11 2:06 AM, Peter Toft wrote:
> On Mon, 18 Apr 2011 20:12:24 -0400, Chet Ramey wrote:
>> On 4/14/11 6:19 PM, Peter Toft wrote:
>>
>>> I have an annoying bash-problem on Red Hat Linux 5.x. If I e.g. try to move
>>> to a subdirectory of another directory (e.g. $HOME), where the tab-expand
>>>
On Mon, 18 Apr 2011 20:12:24 -0400, Chet Ramey wrote:
On 4/14/11 6:19 PM, Peter Toft wrote:
I have an annoying bash-problem on Red Hat Linux 5.x. If I e.g. try
to move
to a subdirectory of another directory (e.g. $HOME), where the
tab-expand
works poorly;
Assume $HOME=/home/pto
You should
On 4/14/11 6:19 PM, Peter Toft wrote:
> I have an annoying bash-problem on Red Hat Linux 5.x. If I e.g. try to move
> to a subdirectory of another directory (e.g. $HOME), where the tab-expand
> works poorly;
>
> Assume $HOME=/home/pto
You should see whether or not you have a completion already d
On Fri, 15 Apr 2011 15:07:16 +0800, Clark J. Wang wrote:
On Fri, Apr 15, 2011 at 6:19 AM, Peter Toft wrote:
Hi all
I have been using tcsh for a long time on Red Hat Linux boxes, and
bash on other UNIX-boxes. One thing I really love with tcsh is the
way
I can swiftly operate using the to do
On Fri, Apr 15, 2011 at 6:19 AM, Peter Toft wrote:
> Hi all
>
> I have been using tcsh for a long time on Red Hat Linux boxes, and
> bash on other UNIX-boxes. One thing I really love with tcsh is the way
> I can swiftly operate using the to do auto-complete, when having
> a deep directory hierar
Peter Volkov wrote:
> Bob Proulx пишет:
> > The $0 is the name used to invoke the shell. If it starts with a '-'
> > then this is used to instruct the shell that it is a login shell. The
> > second variable $- is the flags set to the shell. The 'i' for
> > interactive should be in there.
>
> Ac
Peter Volkov schrieb:
Better way to check if shell is login is:
$ shopt | grep login_shell
login_shell on
You don't even have to call an external program:
[[ $(shopt -p login_shell) == *-s* ]]
Regards,
Bernd
--
Bernd Eggink
[EMAIL PROTECTED]
http://sudrala.de
В Пнд, 12/05/2008 в 17:02 -0600, Bob Proulx пишет:
> The $0 is the name used to invoke the shell. If it starts with a '-'
> then this is used to instruct the shell that it is a login shell. The
> second variable $- is the flags set to the shell. The 'i' for
> interactive should be in there.
Ac
Carl Wenrich wrote:
> I just log into the box that appears on the standard ubuntu
> startup. I enter my username and password, then the desktop comes
> up.
You are using GDM (GNOME Display Manager) then. In which case it
won't automatically start up shells as login shells. It is a quirk of
how t
I just log into the box that appears on the standard ubuntu startup. I enter my
username and password, then the desktop comes up.
I see now that the .bash_profile isn't being sourced (I thought it was
according to what I've been able to pick up on the web). If I source it
manually, the $PATH ge
Carl Wenrich wrote:
> echo $0 gives me "bash"
> echo $- gives me "himBH"
Then bash hasn't been invoked as a login shell and therefore isn't
instructed to source the .bash_profile.
> If it is not a login shell then to suggest improvements it would be
> necessary to know the type of system you are
echo $0 gives me "bash"
echo $- gives me "himBH"
Bob Proulx <[EMAIL PROTECTED]> wrote: Carl Wenrich wrote:
> Bob Proulx wrote:
> > Did you log in after having made that change? Was bash invoked as
> > an interactive login shell so that it would read that file?
> >
> > echo $0
> > echo $-
>
>
Carl Wenrich wrote:
> Bob Proulx wrote:
> > Did you log in after having made that change? Was bash invoked as
> > an interactive login shell so that it would read that file?
> >
> > echo $0
> > echo $-
>
> Yes. I (1) made the change to .bash_profile, then (2) restarted the
> machine, then (3)
Yes. I (1) made the change to .bash_profile, then (2) restarted the machine,
then (3) logged in again. When I echo $PATH the /opt/lampp/bin is not included.
Bob Proulx <[EMAIL PROTECTED]> wrote: carlwenrich wrote:
> I put this in my .bash_profile:
>
> PATH=$PATH:/opt/lampp/bin
> export PATH
>
>
carlwenrich wrote:
> I put this in my .bash_profile:
>
> PATH=$PATH:/opt/lampp/bin
> export PATH
>
> but when I "echo $PATH" it doesn't include the /opt/lampp/bin.
The .bash_profile is sourced by bash when it is invoked as an
interactive login shell. Therefore you would need to log in after
hav
Paul Jarc wrote:
> Jérémy Hervé wrote:
> > -bash: /usr/sbin/httpd: No such file or directory
>
> "hash -r" will fix that. See "help hash" and "man bash" for details.
There is also checkhash.
shopt -s checkhash
In man bash:
checkhash
If set, bash checks that a command fou
Ha...
Ok, Ok... Thanks you, Sven, Paul, Bob for your answers ; I'll thought
it was a bug. I think I must use my last days of holidays learning to
read...
Excuse-me again !
I will wake-up smarter tomorow morning :D
Regards,
Jérémy
___
Bug-bash ma
"Jérémy Hervé" <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED]:/usr/bin# httpd -v
> -bash: /usr/sbin/httpd: No such file or directory
"hash -r" will fix that. See "help hash" and "man bash" for details.
paul
___
Bug-bash mailing list
Bug-bash@gnu.org
On Fri, Aug 03, 2007 at 04:32:10PM +0200, J?r?my Herv? wrote:
> - version : 3.1.17(2)-release (i486-slackware-linux-gnu)
> - description : Strange behaviour ; second time I have it. I removed
> an old apache package (1.3, /usr/sbin/httpd) and make;make-installed a
> new one (/usr/bin/httpd). Here i
> Thank you for wonderful software to which I'm indebted every day.
Thanks for your kind words.
> I have one question.
>
> Why be not consistent path of patch ?
> ex) "../bash-3.2-patched/", "../bash-3.2.9/", "../bash-3.2.11/"
Because it doesn't matter -- `patch' doesn't care.
Chet
--
``The
On Sat, Aug 12, 2006 at 01:51:12AM -0600, Bob Proulx wrote:
> Stephane Chazelas wrote:
> > [ -e "$cmd" ] || cmd=$(command -v -- "$cmd") || exit
> > Bob Proulx wrote:
> > > Of course using command as you have done will work for bash.
> >
> > "command" is a POSIX command. So will work with every P
[EMAIL PROTECTED] (Bob Proulx) writes:
>> 2- word splitting when IFS contains non-blank characters varies
>> from one shell to the next, and in most implementations
>> (including bash and AT&T ksh, it differs from the way the shell
>> splits $PATH internally to look up a command ("/bin:" is "/bin"
Stephane Chazelas wrote:
> [ -e "$cmd" ] || cmd=$(command -v -- "$cmd") || exit
> Bob Proulx wrote:
> > Of course using command as you have done will work for bash.
>
> "command" is a POSIX command. So will work with every POSIX and
> therefore every Unix conformant sh.
That is not strictly tru
On Thu, Jul 13, 2006 at 11:53:00PM -0600, Bob Proulx wrote:
> Stephane Chazelas wrote:
> > $0 will always contain the file path, unless the script was
> > started as:
> >
> > bash script.sh
> >
> > And there's no script.sh in the current directory (in which case
> > sh/bash will have looked up scr
Stephane Chazelas wrote:
> $0 will always contain the file path, unless the script was
> started as:
>
> bash script.sh
>
> And there's no script.sh in the current directory (in which case
> sh/bash will have looked up script.sh in $PATH).
Of course using command as you have done will work for ba
Hi,
On 7/12/06, Stephane Chazelas <[EMAIL PROTECTED]> wrote:
On Tue, Jul 11, 2006 at 08:19:34PM -0400, Dave Rutherford wrote:
> On 7/11/06, Cai Qian <[EMAIL PROTECTED]> wrote:
> >I want its full pathname using 'dirname', but it will give me
> >unexpected result on some Linux or Bash versions.
>
On Tue, Jul 11, 2006 at 08:19:34PM -0400, Dave Rutherford wrote:
> On 7/11/06, Cai Qian <[EMAIL PROTECTED]> wrote:
> >I want its full pathname using 'dirname', but it will give me
> >unexpected result on some Linux or Bash versions.
>
> Well, 'dirname' certainly won't do what you want, but I'm sor
On 7/11/06, Cai Qian <[EMAIL PROTECTED]> wrote:
I want its full pathname using 'dirname', but it will give me
unexpected result on some Linux or Bash versions.
Well, 'dirname' certainly won't do what you want, but I'm sorry,
I can't think of a way to get what you need. (It would be relatively
Hi,
I want its full pathname using 'dirname', but it will give me
unexpected result on some Linux or Bash versions.
Qian
On 7/11/06, Dave Rutherford <[EMAIL PROTECTED]> wrote:
On 7/11/06, Cai Qian <[EMAIL PROTECTED]> wrote:
> In some Linux, it will print "/tmp/script.sh", while in other, it wi
On 7/11/06, Cai Qian <[EMAIL PROTECTED]> wrote:
In some Linux, it will print "/tmp/script.sh", while in other, it will
print "script.sh" only. Which is wrong? If both are fine, is there any
better way to make it portable?
Which do you want? (Both are fine.) If you want 'script.sh',
use 'basen
35 matches
Mail list logo
