It's important that sections of ~/.bashrc be ordered correctly to prevent
such issues. Just because someone tells you to add something to the *end*
of your .bashrc does not mean that's necessarily the best place to put it.
1) some boilerplate, including checking whether the shell i
foreground process should modify
.bash_history in that way.
Turns out that this was caused by pressing Ctrl+C when ~/.bashrc
was being evaluated.
Normally, on my PC, ~/.bashrc is very lightweight and I have a
very very small window when I can
press Ctrl+C and have it aborted. But at
foreground process should modify
.bash_history in that way.
Turns out that this was caused by pressing Ctrl+C when ~/.bashrc
was being evaluated.
Normally, on my PC, ~/.bashrc is very lightweight and I have a
very very small window when I can
press Ctrl+C and have it aborted. But at work
I don't quite understand what you are saying or what issue you are
describing.
> Repeat-By:
>
> Add to ~/.bashrc:
>
> . /path/to/non/existent/file
> termbin.clip() {
> nc termbin.com | tee
> }
>
> For testing:
>
> $ echo "
-1-MANJARO #1 SMP Thu Jul 7 16:57:35 UTC
2022 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
Hi everyone!
I create function for interact with termbin.com (pastebin like) service
in my .bashrc:
termbin-
On Tue, Jan 4, 2022 at 3:38 PM Greg Wooledge wrote:
> On Tue, Jan 04, 2022 at 03:34:05PM -0500, Matthew Persico wrote:
> > On Fri, Dec 31, 2021 at 10:33 AM Greg Wooledge
> wrote:
> > > You can edit the file yourself and make it work however you like. You
> > > have the right idea, but I'd write
On Tue, Jan 04, 2022 at 03:34:05PM -0500, Matthew Persico wrote:
> On Fri, Dec 31, 2021 at 10:33 AM Greg Wooledge wrote:
> > You can edit the file yourself and make it work however you like. You
> > have the right idea, but I'd write it like this:
> >
> > if [[ -d ~/.bash_aliases.d ]]; then
> >
On Fri, Dec 31, 2021 at 10:33 AM Greg Wooledge wrote:
> On Thu, Dec 30, 2021 at 08:46:16PM -0800, Kevin O'Gorman wrote:
> > So I propose extending the stanza near the end of .bashrc:
> > if [ -f ~/.bash_aliases ]; then
> > . ~/.bash_aliases
> > fi
>
> T
On Thu, Dec 30, 2021 at 08:46:16PM -0800, Kevin O'Gorman wrote:
> So I propose extending the stanza near the end of .bashrc:
> if [ -f ~/.bash_aliases ]; then
> . ~/.bash_aliases
> fi
That code was written by your operating system vendor, or by your
system administrator, or
o gives a usenet group as an alternative. I did
> not know usenet was still around.
>
> Anyway, my problem is thatI have so many things added to my .bashrc (well
> to .bash_aliases really), and they've become corrupted and tangled over
> time, that I am reluctant to even lo
I see the bash web page on Xubuntu gives this email address for requests
and such. Nice. It also gives a usenet group as an alternative. I did
not know usenet was still around.
Anyway, my problem is thatI have so many things added to my .bashrc (well
to .bash_aliases really), and they&#x
uld
you please explain why? I thought the reason for the behavior > described in
my original post was that bash does not complete > initialization until
.bashrc completes, which doesn't happen until the > emacs process started from
within it completes? OK. You said you enabled jo
On 9/2/21 5:06 PM, C. Yang wrote:
Could you please explain why? I thought the reason for the behavior
described in my original post was that bash does not complete
initialization until .bashrc completes, which doesn't happen until the
emacs process started from within it completes?
OK
Could you please explain why? I thought the reason for the behavior
described in my original post was that bash does not complete initialization
until .bashrc completes, which doesn't happen until the emacs process started
from within it completes? And it s
sh
> shell. But technically, bash is still waiting for .bashrc to complete.
This is not correct.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
On Thu, Sep 02, 2021 at 12:15:35PM -0400, C. Yang wrote:
> I can confirm that adding `set -m` before the emacs command in .bashrc results
>
> in the behavior I want with CTRL+Z. As I understand, `set -m` will enable job
>
> control features. This suffices for my use case.
>
&
.bashrc results
in the behavior I want with CTRL+Z. As I understand, `set -m` will enable job
control features. This suffices for my use case.
However, is it possible that there may be further unexpected consequences,
since bash is still waiting to complete initialization this entire time?
For
On 9/1/21 2:10 PM, C. Yang wrote:
> Machine: x86_64
> OS: linux-gnu
> Compiler: gcc
> Description:
>
> Whenever I start my session, I'd like to automatically open emacs to a
> specific file.
>
> So, I added the emacs command to the bottom of my ~/.
On Wed, Sep 01, 2021 at 09:28:55PM -0500, Dennis Williamson wrote:
> On Wed, Sep 1, 2021, 8:42 PM Greg Wooledge wrote:
> > I tested with "set -m" and "vim & fg" just now, and it appeared to work.
>
> Do processes started in .bashrc have a terminal? I would
; > It sounds like Bash doesn't activate the job-control features until
> > .bashrc is completed.
>
> Well, there's an easy fix for that. Just put "set -m" before the
> last two commands.
>
> I tested with "set -m" and "vim & fg" just now
On Wed, Sep 01, 2021 at 09:37:02PM -0400, Dale R. Worley wrote:
> "C. Yang" writes:
> > emacs test.txt &
> >
> > fg
>
> > bash: fg: no job control
> It sounds like Bash doesn't activate the job-control features until
> .bashrc is completed.
"C. Yang" writes:
> This may be because the bashrc file is still running, and bash itself
> perhaps does not finish initializing until everything in the bashrc
> completes. This may be why CTRL+Z does not work correctly (it might
> require bash to finish initializing first
From: cheshire (he...@cheryllium.com)
To: mailto:bug-bash@gnu.org
Subject: Interactive commands cant be backgrounded if run from bashrc
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
-fdebug
On Thu, Apr 09, 2020 at 09:48:37AM -0400, Chet Ramey wrote:
> On 4/8/20 7:46 PM, Eduardo Bustamante wrote:
> > On Wed, Apr 8, 2020 at 2:42 PM Martin Schulte
> > wrote:
> > (...)
> >> But, as far as I understand, a non-interactive bash doesn't read
> >
On 4/8/20 7:46 PM, Eduardo Bustamante wrote:
> On Wed, Apr 8, 2020 at 2:42 PM Martin Schulte
> wrote:
> (...)
>> But, as far as I understand, a non-interactive bash doesn't read
>> ~/.bashrc at all - so shouldn't we just omit them?
>
> There are exceptions
On Wed, Apr 08, 2020 at 04:46:19PM -0700, Eduardo Bustamante wrote:
> On Wed, Apr 8, 2020 at 2:42 PM Martin Schulte
> wrote:
> (...)
> > But, as far as I understand, a non-interactive bash doesn't read
> > ~/.bashrc at all - so shouldn't we just omit them?
>
&
On Wed, Apr 8, 2020 at 2:42 PM Martin Schulte wrote:
(...)
> But, as far as I understand, a non-interactive bash doesn't read
> ~/.bashrc at all - so shouldn't we just omit them?
There are exceptions. One of them being SSH, see:
https://git.savannah.gnu.org/cgit/bash.gi
Hello bash developers,
my apologies in advance if I'm overlooking something trivial but I'm
really wondering about the first lines in examples/startup-files/bashrc
(which are copied to Debian's skeleton ~/.bashrc):
case $- in
*i*);;
*) return ;;
esac
Well, bash terminat
On 2/16/20 3:15 PM, Tycho Kirchner wrote:
> Dear bash-maintainers,
>
>
> Description:
> When another instance of bash is called *within the .bashrc* using the
> exec-builtin within a tty (e.g. Ctrl+Alt+F1) the following error occurs:
>
> initialize_job_co
Dear bash-maintainers,
Description:
When another instance of bash is called *within the .bashrc* using the
exec-builtin within a tty (e.g. Ctrl+Alt+F1) the following error
occurs:
initialize_job_control: no job control in background: Bad file
descriptor
On the next
On 2019/10/24 10:47:52 -0400, Greg Wooledge wrote:
> On Thu, Oct 24, 2019 at 09:01:07AM +0200, francis.montag...@inria.fr wrote:
> > When logged on a machine with ssh, executing a simple command CMD1
> > that spawn a "/bin/bash -c some other command" do not sourc
Seems to be down to:
bash-5.0$ printenv SHLVL
1
bash-5.0$ printenv SHLVL | cat
0
Possibly a consequence of the fix for
https://lists.gnu.org/archive/html/bug-bash/2016-09/msg0.html
--
Stephane
On Thu, Oct 24, 2019 at 09:01:07AM +0200, francis.montag...@inria.fr wrote:
> When logged on a machine with ssh, executing a simple command CMD1
> that spawn a "/bin/bash -c some other command" do not source
> ~/.bashrc: normal behaviour.
>
> When executing "
UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Bash Version: 5.0
Patch Level: 7
Release Status: release
Description:
When logged on a machine with ssh, executing a simple command CMD1
that spawn a "/bin/bash -c some other command" do not source
oo /bin/bash' \
> --tab -e 'env PROFILE=bar /bin/bash' \
> --tab
OK. This looks reasonable. Or, if you prefer, you could set up several
different .bashrc-xxx files and use /bin/bash --rcfile ~/.bashrc-xxx
for whichever tab. Or skip the actual files, and embed the commands yo
but doing it everyday for years, sometimes multiple times
a day, gets a bit annoying... plus laziness...).
So I need to be able to recognize which tab is being started,
from my ~/.bashrc, to execute the proper commands for this tab.
I start gnome-terminal, from a script bound to a keyboard key
(I
On Tue, 28 Mar 2017 19:13:55 +0200
Torka Noda wrote:
> On Mon, 27 Mar 2017 10:04:16 -0400
> Daniel Mills wrote:
> >
> > Because you want the positional parameters set with bash -s
> > to take precedence over anything set in the startup files.
> > Otherwise an
On Wed, Mar 29, 2017 at 04:10:14PM +0200, Torka Noda wrote:
> Well, sorry for the confusion, I'll stop here. I think it's
> weird for Bash's positional parameters, and the whole argument
> list if modified with '-s', not to be accessible from
> initialization files, but `env` does what I want relat
===
$ bash -c 'echo' foo bar
$ bash -c 'echo $0 $1 $2' bash foo bar
bash foo bar
====
I now understand better what Daniel Mills was saying...
... except that `echo 'echo $1 $2' | bash -s foo bar` would n
On 3/28/17 12:43 PM, Torka Noda wrote:
> Actually, shouldn't `bash -s`, without any command fed to its
> stdin, exit immediately, anyway...?
No. Why? It reads and executes commands from its standard input, which is
in most cases, the terminal. However, `bash -s foo Plus there is
> apparently no
On 3/28/17 1:13 PM, Torka Noda wrote:
> Modifying positional parameters with `set --` isn't supposed to
> modify the shell's behavior live, anyway. The command line is
> already parsed and options already set. So Bash should always
> use the original arguments specified on the command line, to
> p
On Mon, 27 Mar 2017 10:04:16 -0400
Daniel Mills wrote:
>
> Because you want the positional parameters set with bash -s
> to take precedence over anything set in the startup files.
> Otherwise anything in .bashrc would simply override what you
> set with bash -s.
>
They coul
On Tue, 28 Mar 2017 10:29:57 -0400
Chet Ramey wrote:
> On 3/27/17 8:32 AM, Torka Noda wrote:
> > On Sat, 25 Mar 2017 15:33:47 -0400
> > Chet Ramey wrote:
> >>>
> >>> Is it normal for Bash positional parameters not to be
> >>> available from
On 3/27/17 8:32 AM, Torka Noda wrote:
> On Sat, 25 Mar 2017 15:33:47 -0400
> Chet Ramey wrote:
>>>
>>> Is it normal for Bash positional parameters not to be
>>> available from ~/.bashrc during initialization?
>>
>> Yes. Bash has always worked like th
le arguments if
> we just want the non-option arguments.
>
>
> There definitely are other relatively clean ways (`env` and
> '--rcfile', most notably), but using `bash -s foo bar` and
> handling the positional parameters from ~/.bashrc, would be the
> cleanest for small
On Sat, 25 Mar 2017 15:33:47 -0400
Chet Ramey wrote:
> >
> > Is it normal for Bash positional parameters not to be
> > available from ~/.bashrc during initialization?
>
> Yes. Bash has always worked like this. The startup files are
> read before the positio
On 3/25/17 12:40 AM, Torka Noda wrote:
> ~/.bashrc:
> ==
> #!/bin/bash
> if [ -n "$1" ]; then
> echo "\$1 set ($1)"
> else
> echo '$1 not set!'
> fi
> ==
>
>
On Sat, 25 Mar 2017 05:40:18 +0100
Torka Noda wrote:
>
> The problem is that while PS1=foo is available once Bash has
> finished initializing (i.e., from the command line), it is not
> available from my ~/.bashrc, during initialization.
>
I meant 1=foo, here and in the title..
27;
-DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I./include -I.
-I./include -I./lib
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin'
-DSTANDARD_UTILS_PATH='/bin:/
On Mon, Jan 16, 2017 at 06:01:24PM +0100, Daniel Bullard wrote:
> what do i do?
First, stop top-posting.
Second, stop taking list questions to private email. (I've remembered
one of the list addresses to add back to the Cc: list, but not the other.)
Third, add the missing "fi" line at the end.
On Sun, Jan 15, 2017 at 08:44:24PM +0100, Daniel Bullard wrote:
> # enable programmable completion features (you don't need to enable
> # this, if it's already enabled in /etc/bash.bashrc and /etc/profile
> # sources /etc/bash.bashrc).
> if ! shopt -oq posix; then
> if [ -f /usr/share/bash-comple
tus bluez | grep '^Version:'
bluetoothd -v
sudo apt-get dist-upgrade
sudo reboot
pkgs
apt-get pkgs
lsb_release -a command
lsb_release -a
sudo dpkg -l | grep bluez
sudo dpkg -l | grep bluez tools
sudo dpkg -l | more
cat /var/log/dpkg.log | grep " install "
cat /var/log/dpkg.log
On 2/20/16 4:25 AM, Andrew Gregory wrote:
> Bash Version: 4.3
> Patch Level: 42
> Release Status: release
>
> Description:
> If run non-interactively with stdin closed and SHLVL=0, bash will
> source ~/.bashrc, due to run_startup_files() thinking that bash is
&g
sion: 4.3
Patch Level: 42
Release Status: release
Description:
If run non-interactively with stdin closed and SHLVL=0, bash will
source ~/.bashrc, due to run_startup_files() thinking that bash is
being run by rshd.
Repeat-By:
#include
#include
void main(void) {
close(0);
s
On 1/10/15 12:52 PM, Georges Kesseler wrote:
> Bash Version: 4.2
> Patch Level: 45
> Release Status: release
>
> Description:
> "history -r" called inside .bashrc does not respect HISTTIMEFORMAT.
> Reads timestamps in as
> history entries. Callin
0-15-generic #25-Ubuntu SMP Thu Jan 30
17:22:01 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-pc-linux-gnu
Bash Version: 4.2
Patch Level: 45
Release Status: release
Description:
"history -r" called inside .bashrc does not respect HISTTIMEFORMAT.
Reads timestamps in as
On Mon, Nov 24, 2014 at 10:52:30AM -0500, Steve Simmons wrote:
> My preference would be that the search order for any bash dotfiles are
> ~/.bash/file, then ~/.file. It's backwards-compatible, and for those of us
> who have $HOME in a single filesystem across many machines, a symbolic or
> hard lin
On Nov 23, 2014, at 2:08 PM, Chet Ramey wrote:
> On 11/23/14 5:54 AM, Xie Yuheng wrote:
>> we should add ".bash/" along with ".bashrc" as the default init dir.
>> this will make things more flexible, and will not break any existed code.
>> to be "
On 11/23/14 5:54 AM, Xie Yuheng wrote:
> we should add ".bash/" along with ".bashrc" as the default init dir.
> this will make things more flexible, and will not break any existed code.
> to be "default" is important, people who right simple makefile can use
Hi,
do you mean, you want bash to automatically load all files from
~/.bash/ directory? you want it to work as if putting this into
~/.bashrc:
for file in ~/.bash/*; do
if [ -f "${file}" ]; then
. "${file}";
fi;
done;
is that right?
cheers,
pg
On Sun, Nov 23, 2
we should add ".bash/" along with ".bashrc" as the default init dir.
this will make things more flexible, and will not break any existed code.
to be "default" is important, people who right simple makefile can use
this, only when it is "default".
> I don't know what version of bash you replaced, but it's likely that Red
> > Hat defined that option before building the version of bash shipped with
> > Fedora 6. It's been there for 15 years.
>
>
> Also must be present on much more recent Oracle Linux, and in fact I never
> found other behav
El sábado, 8 de noviembre de 2014, Chet Ramey
escribió:
This is controlled by the NON_INTERACTIVE_LOGIN_SHELLS option in
> config-top.h. It's not enabled by default. Define that option and
> rebuild, and you should have the behavior you want.
Thank you, Thank you, Thank you!
It's late at ni
.3.tar.gz plus patches and compile it)
>
> Today I realized some processes were not working as expected. After some
> investigation I've realized that when executing commands as:
>
> su - [user] -c [command]
>
> neither .bashrc o .bash_profile on user home director
El sábado, 8 de noviembre de 2014 09:14:17 UTC+1, Piotr Grzybowski escribió:
> Hi,
>
> a bit strange. I do not think it is related to the patches.
> have added the path to your newly compiled and patched shell to /etc/shells?
No, I didn't. In fact I just replaced the original bash with the com
realized that when executing commands as:
>
> su - [user] -c [command]
>
> neither .bashrc o .bash_profile on user home directory are executed. If I
> just execute
>
> su - [user]
>
> everything it's fine.
>
> I've changed the user shell on /etc/passwd to the p
ng as expected. After some
investigation I've realized that when executing commands as:
su - [user] -c [command]
neither .bashrc o .bash_profile on user home directory are executed. If I just
execute
su - [user]
everything it's fine.
I've changed the user shell on /etc/pa
On 5/1/13 6:53 AM, cetteadressem...@free.fr wrote:
> Machine Type: x86_64-unknown-linux-gnu
>
> Bash Version: 4.2
> Patch Level: 45
> Release Status: release
>
> Description:
> I know this is something odd to do, I would like to start my windows
> manager
>
64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu
Bash Version: 4.2
Patch Level: 45
Release Status: release
Description:
I know this is something odd to do, I would like to start my windows
manager
from .bashrc.
If I do so and hit ctrl-z while bash is asking me for command line
Ilya Basin wrote:
> > There is a compile time option to cause bash to check for the
> > SSH_CLIENT[2] environment variables but it seems arch doesn't
> > enable it for its build.
And that has been a contentious issue. Some people like it. Some
people hate it. If you don't have it th
On Wed, Apr 24, 2013 at 9:15 AM, Ilya Basin wrote:
> **
>
> >
>
>
>
>
>
>
> On Wed, Apr 24, 2013 at 7:31 AM, Ilya Basin wrote:
>
>
> Hi.
>
>
> $ cat ~/.bashrc
>
> #
>
> # ~/.bashrc
>
> #
>
> echo
>
On Wed, Apr 24, 2013 at 7:31 AM, Ilya Basin <[1]basini...@gmail.com>
wrote:
Hi.
$ cat ~/.bashrc
#
# ~/.bashrc
#
echo Im in .bashrc >&2
RHEL 6.0, bash 4.1.2
$ ssh localhost 'ps -f $$ &&
On Wed, Apr 24, 2013 at 7:31 AM, Ilya Basin wrote:
> Hi.
>
> $ cat ~/.bashrc
> #
> # ~/.bashrc
> #
> echo Im in .bashrc >&2
>
> RHEL 6.0, bash 4.1.2
> $ ssh localhost 'ps -f $$ && true'
> Im in .bashrc
&g
Hi.
$ cat ~/.bashrc
#
# ~/.bashrc
#
echo Im in .bashrc >&2
RHEL 6.0, bash 4.1.2
$ ssh localhost 'ps -f $$ && true'
Im in .bashrc
UIDPID PPID C STIME TTY STAT TIME CMD
git 22295 22294 0 08:29 ?Ss 0:00
Hi Chris,
Yes, I use temporally my ISP, wanad... and don't have too much control
over.
In few time i have my servers up and running again, and full control.
Greetings,
Jose Luis
PS: Hope more luck now in format.
---Mensaje original---
Don't worry about it.
As an aside, y
n:
> On open console/terminal the aliases on .bash_aliases don't are
avalaible.
>
> Repeat-By:
> A.- Open terminal
> B.- type/call any alias in ".bash_aliases" e.g. cls
> C.- Press enter
> D.- Message error "No se ha encontrad
On 2013-02-26 01:17, Uroz Gonzalez, Jose Luis wrote:
> Hi Chris,
>
> The output is:
>
> es un alias de `cd ~' ( . is an alias of "cd ~")
>
> My apologies.
>
> Some days ago I tested aliases to best use and tested this, but not deleted.
> On restarting system I forgot completely. Sorry.
>
> From no
> D.- Message error "No se ha encontrado la orden «cls» pero hay 18
> similares
> cls: no se encontró la orden"
>
> Fix:
> Prepend a slash "\" to dot on .bashrc.
> This:
> . ~/.bash_aliases
> To this:
> \. ~/.bash_aliases
>
>
>
Something is really wrong with your shell configuration if you have to do this.
What is the output of `type .`?
Chris
ible.
Repeat-By:
A.- Open terminal
B.- type/call any alias in ".bash_aliases" e.g. cls
C.- Press enter
D.- Message error "No se ha encontrado la orden «cls» pero hay 18
similares
cls: no se encontró la orden"
Fix:
Prepend a slash "\" to dot on .bashrc.
This:
. ~/.bash_aliases
To this:
\. ~/.bash_aliases
On 8/10/12 3:05 AM, Clark WANG wrote:
> For quite a long time I don't know why my bash stops remembering command
> history. I just figured out it was caused by some code like `eval return'
> in the .bashrc/.bash_profile.
Thanks for the report. As you suspected, the combination
For quite a long time I don't know why my bash stops remembering command
history. I just figured out it was caused by some code like `eval return'
in the .bashrc/.bash_profile.
Steps to reproduce (tested with 3.2.25, 4.0.28, 4.1.11 and 4.2.29):
$ cp .bashrc .bashrc.old
$ echo e
the feature in bash. It's still there
today.
I guess I'm just looking for confirmation that what I'm doing is correct. I've
been going to some lengths to ensure that the environment that I get for a
non-interactive script gets at least the minimal environment that I expect.
is being run with its
> standard input connected to a network connection, as when
> executed by the remote shell daemon, usually rshd, or the
> secure shell daemon sshd. If bash determines it is being
> run in this fashion, it reads and executes c
On Sun, Jun 3, 2012 at 11:02 AM, Linda Walsh wrote:
>
>
> Pierre Gaston wrote:
>>
>> In all your examples the shell will be called like: bash -c 'isatty 0
>> 2'. If you use a bash compiled with the above option you can add 'ps
>> -p$$ -ocmd'
Pierre Gaston wrote:
In all your examples the shell will be called like: bash -c 'isatty 0
2'. If you use a bash compiled with the above option you can add 'ps
-p$$ -ocmd' at the top of your .bashrc to verify it.
They are all non-interactive because they are called with
On Sun, Jun 3, 2012 at 3:05 AM, Linda Walsh wrote:
>
>
> Pierre Gaston wrote:
>
>> On Sat, Jun 2, 2012 at 8:24 PM, Mikel Ward wrote:
>>>
>>> On Sat, Jun 2, 2012 at 10:19 AM, Pierre Gaston
>>> wrote:
>>>>
>>>> On Sat, Jun 2,
Pierre Gaston wrote:
On Sat, Jun 2, 2012 at 8:24 PM, Mikel Ward wrote:
On Sat, Jun 2, 2012 at 10:19 AM, Pierre Gaston wrote:
On Sat, Jun 2, 2012 at 8:15 PM, Mikel Ward wrote:
bash sources .bashrc even for some non-interactive shells.
...
"Remote non login non interactive shells&
On Sat, Jun 2, 2012 at 8:24 PM, Mikel Ward wrote:
> On Sat, Jun 2, 2012 at 10:19 AM, Pierre Gaston
> wrote:
>> On Sat, Jun 2, 2012 at 8:15 PM, Mikel Ward wrote:
>>> bash sources .bashrc even for some non-interactive shells.
> ...
>> "Remote non login no
On Sat, Jun 2, 2012 at 10:19 AM, Pierre Gaston wrote:
> On Sat, Jun 2, 2012 at 8:15 PM, Mikel Ward wrote:
>> bash sources .bashrc even for some non-interactive shells.
...
> "Remote non login non interactive shells"
> Bash has a special compile time option that will
or a network shell
On Sat, Jun 2, 2012 at 10:15 AM, Mikel Ward wrote:
> bash sources .bashrc even for some non-interactive shells.
>
> For example with
>
> echo \$- is $-
>
> in ~/.bashrc, and shell set to /bin/bash (bash 4.2.28)
>
> ssh -n -T localhost true
>
>
On Sat, Jun 2, 2012 at 8:15 PM, Mikel Ward wrote:
> bash sources .bashrc even for some non-interactive shells.
>
> For example with
>
> echo \$- is $-
>
> in ~/.bashrc, and shell set to /bin/bash (bash 4.2.28)
>
> ssh -n -T localhost true
>
> produces
bash sources .bashrc even for some non-interactive shells.
For example with
echo \$- is $-
in ~/.bashrc, and shell set to /bin/bash (bash 4.2.28)
ssh -n -T localhost true
produces the output
$- is hBc
I assume this is caused by this code in shell.c
if (run_by_ssh
e servers' root
> > > > passwords are well known so anybody can easily su to my account to
> > > > access my files. To protect some private info in my bashrc I want to
> > > > encrypt it. Any one has a good solution for that?
>
> The private informat
my files.
> To protect some private info in my bashrc I want to encrypt it. Any one has
> a good solution for that?
if they have root, they have access to all memory and devices. including your
terminal where you enter the passphrase/key, or the memory where the file is
decrypted/read. encry
anybody can easily su to my account to
> > > access my files. To protect some private info in my bashrc I want to
> > > encrypt it. Any one has a good solution for that?
The private information should be in a separate file, not in ~/.bashrc
itself.
> I've ever tried openssl an
t; NIS to manage user accounts. The bad thing is that some servers' root
> > > passwords are well known so anybody can easily su to my account to
> > > access my files. To protect some private info in my bashrc I want to
> > > encrypt it. Any one has a good solution
; passwords are well known so anybody can easily su to my account to
> > access my files. To protect some private info in my bashrc I want to
> > encrypt it. Any one has a good solution for that?
>
> From top of my head:
>1. gpg
>2. openssl
>
I've ever tried o
ess my files. To protect some private info in my bashrc I want to
> encrypt it. Any one has a good solution for that?
>From top of my head:
1. gpg
2. openssl
--
William
In my company all the people share a few of Solaris servers which use NIS
to manage user accounts. The bad thing is that some servers' root passwords
are well known so anybody can easily su to my account to access my files.
To protect some private info in my bashrc I want to encrypt it. An
On Thu, Oct 27, 2011 at 11:43 AM, Greg Wooledge wrote:
> On Thu, Oct 27, 2011 at 04:39:23PM +, Stephane CHAZELAS wrote:
>> You mean you'd like every bash script you run on your system to
>> automatically source your ~/.bashrc.
>>
>> That sounds like a very unw
1 - 100 of 136 matches
Mail list logo
