Re: Only one Friday 13th coming in 2016
On Tue, Dec 22, 2015 at 04:04:16AM +0100, Ángel González wrote:
> Aren't you making things more complex than needed, with so much pipes
> and awk?
>
> date(1) is your friend:
>
> For instance:
> $ for y in {1900..2199} ; do echo -n "$y "; for m in {1..12}; do date +%A -d
> $y-$m-13; done | grep -c Friday ; done
>
> shows there are between 1 and 3 Fridays per year.
This is the most obvious approach, but it does a fair amount of forking.
Also, you're relying on GNU date. There's no portable way to do simple
date lookups in a shell script, unfortunately.
A pure-bash approach that avoids forking might look something like:
t=946702800 # Start at Sat Jan 1 12:00:00 EST 2000
endyear=2036
while true; do
printf -v year '%(%Y)T' "$t"
((year > endyear)) && break
printf -v day '%(%d)T' "$t"
printf -v dow '%(%w)T' "$t"
if [[ $day = 13 && $dow = 5 ]]; then
printf -v month '%(%m)T' "$t"
echo "$year-$month-$day"
fi
((t += 86400))
done
But just because it doesn't fork, doesn't mean it's *fast*. Bash is so
slow at everything. :( Your one-fork-per-month loop (plus one fork per
year) might end up being much faster than my zero-forks-per-day loop.
Mine is portable, though.
Re: Only one Friday 13th coming in 2016
2015-12-22 08:16:28 -0500, Greg Wooledge:
[...]
> t=946702800 # Start at Sat Jan 1 12:00:00 EST 2000
> endyear=2036
>
> while true; do
> printf -v year '%(%Y)T' "$t"
> ((year > endyear)) && break
> printf -v day '%(%d)T' "$t"
> printf -v dow '%(%w)T' "$t"
> if [[ $day = 13 && $dow = 5 ]]; then
> printf -v month '%(%m)T' "$t"
> echo "$year-$month-$day"
> fi
> ((t += 86400))
> done
>
> But just because it doesn't fork, doesn't mean it's *fast*. Bash is so
> slow at everything. :( Your one-fork-per-month loop (plus one fork per
> year) might end up being much faster than my zero-forks-per-day loop.
> Mine is portable, though.
[...]
(assumes a recent version of bash though).
Starting on a Friday and looping with ((t += 7*86400)) and look
for %d == 13 would be more efficient.
TZ=UTC0 perl -MPOSIX -le 'for ($i=86400;$i<2**31;$i+=7*86400) {
@t=gmtime($i); if ($t[3] == 13){print strftime"%c",@t}}'
only takes a few miliseconds here.
--
Stephane
Re: Only one Friday 13th coming in 2016
Am Tue, 22 Dec 2015 08:16:28 -0500
schrieb Greg Wooledge :
> On Tue, Dec 22, 2015 at 04:04:16AM +0100, Ángel González wrote:
> > Aren't you making things more complex than needed, with so much
> > pipes and awk?
> >
> > date(1) is your friend:
> >
> > For instance:
> > $ for y in {1900..2199} ; do echo -n "$y "; for m in {1..12}; do
> > date +%A -d $y-$m-13; done | grep -c Friday ; done
> >
> > shows there are between 1 and 3 Fridays per year.
>
> This is the most obvious approach, but it does a fair amount of
> forking. Also, you're relying on GNU date.
And on the assumption that Friday is called „Friday“ in the used locale
which is a bit surprising since Ángel's name suggests that it is called
differently in his native locale. It is called „Freitag“ in mine so I
got no Friday 13th at all.
Re: Feature discussion - startup files
On Mon, 21 Dec 2015, Chet Ramey wrote: My position is that a feature like this is not popular enough to be made the default, and the way to move forward and make something like it available is to make it a configurable option. The standard way to do that is to make it an option in config-top.h, but it could be settable using configure. My two cents: bash doesn't need any more initialization files. There are already too many opportunities to screw around with what the shell does at startup that cannot be easily overridden or avoided by the user, and vendors already abuse this with all manner of crap they think desirable. Another avenue for this sort of behavior, configurable or otherwise, will just result in more of the same -- with the same claims of "no support!" any time anyone tries to change the as-shipped defaults. The end result will be no different from the current situation. Further, the "do it, regardless" aspect of this proposal is particularly worrisome: the last thing anyone needs is another unconditionally sourced system-wide file in the style of bash_logout. No more, please. -Rob
Re: Feature discussion - startup files
On Mon, Dec 21, 2015 at 5:17 PM, Ángel González wrote: > Chet Ramey wrote: > > The current configurable startup file options are insufficient for > > their purposes because they can be enabled or disabled by vendors, > > and these folks would rather not modify the "vendor" parts of the > > system. In some cases, with some Linux distributions, doing so voids > > their support. > > How are they going to deal with vendors disabling the new configuration > file, too? > > "Create a new configuration file" is the wrong "solution" to "the > vendor disables existing configuration files". > Vendors do not do it for tcsh or zsh. They also don't do it for /etc/profile. What we are asking for is a file that is always sourced on all shells (at least the interactive ones) just like /etc/profile. The problem is that /etc/bashrc is optional. You have to modify config-top.h to make it work. Chet view that it be made a configuration option is not a viable option for us. It has to be always work in all cases or it will be just like Ángel González and won't be a solution we can use. R. -- Robert McLay, Ph.D. TACC Manager, HPC Software Tools (512) 232-8104
Command-line char insertion segfault
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I../. -I.././include -I.././lib -D_FORTIFY_SOURCE=2 -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall uname output: Linux SZ30 3.16.0-38-generic #52~14.04.1-Ubuntu SMP Fri May 8 09:43:57 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 4.3 Patch Level: 11 Release Status: release Description: Every time I insert a character in a command-line in a position followed by some characters and some blanks, Bash crashes. Repeat-By: In a new command line, if I type the following 4 keys: [a][SPACE][HOME][s] the Bash process terminates printing "Segmentation fault". This happens both in a Gnome terminal window, and in a text-mode screen.
Re: Feature discussion - startup files
Hi, I much align to Piotr's approach to this. And I'd reiterate his important question: "How much harm can it do?" Well, really, if there is a counter argument to inventing such a hook, please put it forward now, because it needs to be considered. I wish config-top.h or configure would be a solution, yet asking all vendors to tune to it, sounds like an exercise in vain; meanwhile, they would be more willing to receive a new feature from upstream bash, which is optional and does no harm. tia for your time, F. On 21 December 2015 at 21:43, Piotr Grzybowski wrote: > Hey, > > As an administrator, when I faced this issue I usually used some > wicked sourcing in standard bash startup files to get one global file > that gets sourced by default (last time I wanted one per group of > users, etc). > It would be useful; at least for me. How much harm can it do? If the > file is no existent, the behaviour is unchanged. There is no > significant performance impact. If it is plainly mentioned in the man > I have no problem with enabling it by default. > Personally I think that the list should be used to propose the new > features, and ask for them. When the maintainer is being approached > and then he approaches the list it may stop some (not all ;-)) to > shout "what a stupid idea that is". > > sincerely, > pg > > > On Mon, Dec 21, 2015 at 9:19 PM, Chet Ramey wrote: > > I've been approached by some HPC system administrators (who have the > > unenviable task of supporting thousands of users) who have requested a > > new feature in bash: a system startup file with a fixed name (e.g., > > /etc/bashenv) that is sourced by every instance of bash. The initial > > request was for something sourced by every interactive shell, but the > > presence of batch systems in the HPC environments prompted the request > > for this kind of startup file for non-interactive shells as well. > > > > The current configurable startup file options are insufficient for their > > purposes because they can be enabled or disabled by vendors, and these > > folks would rather not modify the "vendor" parts of the system. In some > > cases, with some Linux distributions, doing so voids their support. > > > > My position is that a feature like this is not popular enough to be made > > the default, and the way to move forward and make something like it > > available is to make it a configurable option. The standard way to do > > that is to make it an option in config-top.h, but it could be settable > > using configure. > > > > I'm interested in hearing what other folks think about the issue, and > > the shell configuration challenges system administrators face in general. > > > > Chet > > -- > > ``The lyf so short, the craft so long to lerne.'' - Chaucer > > ``Ars longa, vita brevis'' - Hippocrates > > Chet Ramey, ITS, CWRUc...@case.edu > http://cnswww.cns.cwru.edu/~chet/ > > > -- echo "sysadmin know better bash than english"|sed s/min/mins/ \ | sed 's/better bash/bash better/' # signal detected in a CERN forum
Re: Feature discussion - startup files
Hi Rob, IMHO, the crap of vendors that you mentioned is very real and, it is largely caused by -and not causing- lack of a single place for applying environment tuning/control. Compare bash vs zsh: http://blog.flowblok.id.au/static/images/shell-startup-actual.png # if you have similar diagram for your distro, please post! fi. HPC systems rely on environment modules [1] and bash is still particularly tricky while using it, after 2 decades :-( . Users on large platforms flee towards other shells (in practice: that's zsh) due to this sticky issue, which is certainly fixable and, we might even get a chance to fix some of bash_logout's annoyances, too. Fotis [1] environment modules is a well tried technology, first appearing in year 1991! ; if you have ever cought yourself to have a messy bash initialization file, check it out because it really helps. In fact, with it you could have most of the common configuration for a handful of shells *in a single place*. On 22 December 2015 at 04:11, Rob Foehl wrote: > On Mon, 21 Dec 2015, Chet Ramey wrote: > > My position is that a feature like this is not popular enough to be made >> the default, and the way to move forward and make something like it >> available is to make it a configurable option. The standard way to do >> that is to make it an option in config-top.h, but it could be settable >> using configure. >> > > My two cents: bash doesn't need any more initialization files. There are > already too many opportunities to screw around with what the shell does at > startup that cannot be easily overridden or avoided by the user, and > vendors already abuse this with all manner of crap they think desirable. > > Another avenue for this sort of behavior, configurable or otherwise, will > just result in more of the same -- with the same claims of "no support!" > any time anyone tries to change the as-shipped defaults. The end result > will be no different from the current situation. > > Further, the "do it, regardless" aspect of this proposal is particularly > worrisome: the last thing anyone needs is another unconditionally sourced > system-wide file in the style of bash_logout. No more, please. > > -Rob > -- echo "sysadmin know better bash than english"|sed s/min/mins/ \ | sed 's/better bash/bash better/' # signal detected in a CERN forum
Re: Command-line char insertion segfault
On 12/21/15 7:38 PM, Carlo Milanesi wrote: > Bash Version: 4.3 > Patch Level: 11 > Release Status: release > > Description: > Every time I insert a character in a command-line in a position > followed by some characters and some blanks, Bash crashes. > > Repeat-By: > In a new command line, if I type the following 4 keys: > [a][SPACE][HOME][s] > the Bash process terminates printing "Segmentation fault". > This happens both in a Gnome terminal window, and in > a text-mode screen. I can't reproduce this. Can you get a stack traceback of the core dump or attach to the bash process using gdb before it crashes and print the stack traceback (using `where') when it crashes? -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Command-line char insertion segfault
On 12/22/2015 03:38 PM, Chet Ramey wrote: On 12/21/15 7:38 PM, Carlo Milanesi wrote: Bash Version: 4.3 Patch Level: 11 Release Status: release Description: Every time I insert a character in a command-line in a position followed by some characters and some blanks, Bash crashes. Repeat-By: In a new command line, if I type the following 4 keys: [a][SPACE][HOME][s] the Bash process terminates printing "Segmentation fault". This happens both in a Gnome terminal window, and in a text-mode screen. I can't reproduce this. Can you get a stack traceback of the core dump or attach to the bash process using gdb before it crashes and print the stack traceback (using `where') when it crashes? Here it is: Program received signal SIGSEGV, Segmentation fault. 0x004a5073 in ?? () (gdb) where #0 0x004a5073 in ?? () #1 0x004a64d5 in rl_redisplay () #2 0x004951de in _rl_internal_char_cleanup () #3 0x004959e9 in readline_internal_char () #4 0x00496075 in readline () #5 0x004215da in ?? () #6 0x00423836 in ?? () #7 0x00426712 in ?? () #8 0x00429cf4 in yyparse () #9 0x00420eeb in parse_command () #10 0x00420fbc in read_command () #11 0x004211b9 in reader_loop () #12 0x0041f759 in main ()
Re: Only one Friday 13th coming in 2016
On Tue, Dec 22, 2015 at 04:04:16AM +0100, Ángel González wrote:
> Bill Duncan wrote:
> > Remember that while there are 14 patterns of years, leap years don't
> > impact Friday the 13th for January/February..
> >
> > This isn't an exhaustive analysis, but a quick check for 300 years
> > didn't show any years without a Friday 13th..
> >
> > ;-)
> >
> > $ for y in {1900..2199} ; do for m in {1..12};do cal $m $y|awk
> > 'FNR==1{m=$0}/^ 1/{print m}';done;done | awk '{y[$2]++} END {for
> > (i=1900;i<2200;i++) if (!(i in y)) print i}'
> > $
>
>
> Aren't you making things more complex than needed, with so much pipes
> and awk?
>
> date(1) is your friend:
>
> For instance:
> $ for y in {1900..2199} ; do echo -n "$y "; for m in {1..12}; do date +%A -d
> $y-$m-13; done | grep -c Friday ; done
>
> shows there are between 1 and 3 Fridays per year.
>
>
> Or a mere listing:
> $ for y in {1900..2199} ; do for m in {1..12}; do date +%A -d $y-$m-13;
> done; done | sort | uniq -c | sort -rn
>
> That the most common weekday in these three centuries for the 13th is??? you
> guessed it, Friday.
Can't resist... cal(1)'s ncal option/version puts all Fridays on a line, so...
$ for y in {1900..2199}; do ncal $y | grep ^Fr | tr \ \\n |
grep 13 | wc -l; done | sort | uniq -c
128 1
128 2
44 3
and using the full range of cal(1) years:
$ time for y in {1..}; do ncal $y | grep ^Fr | tr \ \\n |
grep 13 | wc -l; done | sort | uniq -c
4274 1
4258 2
1467 3
real0m52.301s
user0m33.116s
sys 0m11.816s
and one more pass to count 'Friday the 13th' per month, but I guess
there can only be 0 or 1 anyway, so probably not very interesting:
$ time for m in {1..12}; do echo m=$m; for ((y=1; y<+1; y+=1)); \
do ncal $m $y| grep ^Fr | tr \ \\n | grep 13 | wc -l; done |
sort | uniq -c; done
m=1
8552 0
1447 1
m=2
8574 0
1425 1
m=3
8552 0
1447 1
...
m=11
8553 0
1446 1
m=12
8573 0
1426 1
real10m25.149s
user6m57.916s
sys 2m4.284s
I cheated and edited and filtered the above output to show counts by
month:
1403 8
1405 10
1425 2
1425 6
1426 12
1426 9
1446 11
1447 1
1447 3
1447 4
1447 5
1447 7
For some reason August and October have the fewest Friday the 13th's.
Re: Command-line char insertion segfault
On Tue, Dec 22, 2015 at 8:07 PM, Carlo Milanesi wrote: > On 12/22/2015 03:38 PM, Chet Ramey wrote: >> >> On 12/21/15 7:38 PM, Carlo Milanesi wrote: >>> Description: >>> Every time I insert a character in a command-line in a position >>> followed by some characters and some blanks, Bash crashes. >>> >>> Repeat-By: >>> In a new command line, if I type the following 4 keys: >>> [a][SPACE][HOME][s] >>> the Bash process terminates printing "Segmentation fault". >>> This happens both in a Gnome terminal window, and in >>> a text-mode screen. >> >> >> I can't reproduce this. [..] Neither can I. Tried both linux and mac on i386 and x86_64. Could you send the output of set command, if it does not contain any private/confidential data? Whats your locale? sincerely, pg
Re: Command-line char insertion segfault
On 12/22/2015 09:14 PM, Piotr Grzybowski wrote:
On Tue, Dec 22, 2015 at 8:07 PM, Carlo Milanesi
wrote:
On 12/22/2015 03:38 PM, Chet Ramey wrote:
On 12/21/15 7:38 PM, Carlo Milanesi wrote:
Description:
Every time I insert a character in a command-line in a position
followed by some characters and some blanks, Bash crashes.
Repeat-By:
In a new command line, if I type the following 4 keys:
[a][SPACE][HOME][s]
the Bash process terminates printing "Segmentation fault".
This happens both in a Gnome terminal window, and in
a text-mode screen.
I can't reproduce this. [..]
Neither can I. Tried both linux and mac on i386 and x86_64.
Could you send the output of set command, if it does not contain any
private/confidential data? Whats your locale?
I originally set partially it_IT locales, and partially en_US locales,
then changed all to en_US, but I still have an Italian keyboard.
The output of "set" is about 100 KB, as there is a large "_xspecs"
variable, and a lot of functions (mostly created by Mint).
Removing both from it, the following is the result of "set" in tty1.
BASH=/bin/bash
BASHOPTS=checkwinsize:cmdhist:complete_fullquote:expand_aliases:extglob:extquote:force_fignore:histappend:interactive_comments:progcomp:promptvars:sourcepath
BASH_ALIASES=()
BASH_ARGC=()
BASH_ARGV=()
BASH_CMDS=()
BASH_COMPLETION_COMPAT_DIR=/etc/bash_completion.d
BASH_LINENO=()
BASH_SOURCE=()
BASH_VERSINFO=([0]="4" [1]="3" [2]="11" [3]="1" [4]="release"
[5]="x86_64-pc-linux-gnu")
BASH_VERSION='4.3.11(1)-release'
COLUMNS=170
DIRSTACK=()
EUID=1000
GROUPS=()
HISTCONTROL=ignoreboth
HISTFILE=/home/cmilanesi/.bash_history
HISTFILESIZE=2000
HISTSIZE=1000
HOME=/home/cmilanesi
HOSTNAME=SZ30
HOSTTYPE=x86_64
HUSHLOGIN=FALSE
IFS=$' \t\n'
LANG=en_US.UTF-8
LANGUAGE=en_US:en
LC_ADDRESS=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_TIME=en_US.UTF-8
LESSCLOSE='/usr/bin/lesspipe %s %s'
LESSOPEN='| /usr/bin/lesspipe %s'
LINES=48
LOGNAME=cmilanesi
LS_COLORS='rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.war=01;31:*.ear=01;31:*.sar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.webm=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01
;
35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:*.axa=00;36:*.oga=00;36:*.spx=00;36:*.xspf=00;36:'
MACHTYPE=x86_64-pc-linux-gnu
MAIL=/var/mail/cmilanesi
MAILCHECK=60
OPTERR=1
OPTIND=1
OSTYPE=linux-gnu
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
PIPESTATUS=([0]="0")
PPID=2918
PS1='${debian_chroot:+($debian_chroot)}\[\033[01;32m\]\u@\h\[\033[01;34m\]
\w \$\[\033[00m\] '
PS2='> '
PS4='+ '
PWD=/home/cmilanesi
SHELL=/bin/bash
SHELLOPTS=braceexpand:emacs:hashall:histexpand:history:interactive-comments:monitor
SHLVL=2
TERM=linux
UID=1000
USER=cmilanesi
XDG_RUNTIME_DIR=/run/user/1000
XDG_SEAT=seat0
XDG_SESSION_COOKIE=7ea36d104954aa8a493216e056649de4-1450822200.823706-214057294
XDG_SESSION_ID=c3
XDG_VTNR=1
_=-alF
__git_printf_supports_v=yes
__grub_script_check_program=grub-script-check
_backup_glob='@(#*#|*@(~|.@(bak|orig|rej|swp|dpkg*|rpm@(orig|new|save'
_xspecs=...a lot...
...a lot of functions...
Re: Feature discussion - startup files
On Tue, 22 Dec 2015, Fotis Georgatos wrote:
Compare bash vs zsh:
http://blog.flowblok.id.au/static/images/shell-startup-actual.png # if
you have similar diagram for your distro, please post! fi. HPC systems
rely on environment modules [1] and bash is still particularly tricky
while using it, after 2 decades :-( .
This diagram essentially reiterates my point, if indirectly: not only is
the current startup excessively complex, it's almost impossible to reason
about and/or use with any expectation of getting it right. (Hint: the
bash portion of the diagram doesn't -- but who can blame them?)
Users on large platforms flee towards other shells (in practice: that's
zsh) due to this sticky issue, which is certainly fixable and, we might
even get a chance to fix some of bash_logout's annoyances, too.
If users are already abandoning bash, how is another feature wedged into
bash going to help? I don't follow the reasoning here. Most of what
could be accomplished with this would be better addressed by something
shell-agnostic like pam_env, or by just reminding users that if they want
feature XYZ, they'll need to source /etc/xyz from their shell startup file
of choice, perhaps via functioning examples in their default files...
if you have ever cought yourself to have a messy bash initialization
file, check it out because it really helps.
In fact, with it you could have most of the common configuration for a
handful of shells *in a single place*.
For whatever it's worth, the way I deal with this is to keep a .profile
full of POSIX shell to handle most of the environment setup -- including
undoing the obnoxiousness sourced from vendor files in /etc that I can't
otherwise convince bash to ignore -- which is in turn sourced by this
preamble in my .bashrc:
[[ "$-" != *i* ]] && return
. ~/.profile
Those two plus a .bash_profile link to .bashrc cover most cases of
{,non-}{login,interactive,bash} shells with reasonably correct "just do
what I want" behavior.
-Rob
