Alex McDonald wrote:

I don't know any other language well enough to tell how true that is
for them too.

Computer languages are basicly imperative. You are telling the computer
what to do. Given a list of hardware-specific operations, I think any
turing-complete language should be able to say anything that any other
turing-complete language can say. But they differ in what's *easy* to
say.

Similarly, I think human languages mostly give you similar capabilities
for things that are easy to measure. Things you can point at. Things
where you get quick feedback about whether you misunderstood. About
those things you can usually do easy translation.

But people learn subtle meanings from context. Different cultures give
different subtleties, whether they officially use the same language or
not. And when you learn a different language and a different culture
the details won't quite match up.

yz7502@gmail.com writes:

Are you sourcing this file in your init files anywhere?

Is there some reason why you aren't using M-x shell?

whd

I don't want to detour the attention about the question of William Daffer, but i
also prefer M-x term instead of M-x shell, because the output of M-x shell is
not well formatted compared to M-x term.

Now i put the following question:

What's the difference between M-x shell and M-x term?

How can i configure M-x shell to be well formatted?

One example of the bad formatation of the output of M-x shell, is when i do ls
-la.
I get the following:

]]] file1 ]]] file3^]]] ]]] file5^]]]
]]] file2 ]]] file4^]]] ]]] file6^]]]

With the M-x term i get well formatted:

file1 file3 file5
file2 file4 file6

Citando William Daffer wabcmail.com>:

Hi William,
I used to use M-x shell, but I have one application which requires
X-window, and the dumb term of M-x Shell does not support it.

On the other hand , M-x term seems to miss some env stuff.

Thanks for your reply.

Yadong

yz7502@gmail.com writes:

I assume that your test of 'term mode' happened after setting up your
initialization files such that your normal shell saw these new aliases
and then logging out and back in again, or, in some other way making
those aliases available to whatever process started the emacs you
attempted 'M-x term' in, right?

whd
--
RICH, adj. Holding in trust and subject to an accounting the property
of the indolent, the incompetent, the unthrifty, the envious and the
luckless. That is the view that prevails in the underworld, where the
Brotherhood of Man finds its most logical development and candid
advocacy. To denizens of the midworld the word means good and wise.
-- Ambrose Bierce: _The Devil's Dictionary_

op132650c@mail.telepac.pt writes:

M-x term actually does terminal emulation where M-x shell
doesn't. At least that's the only difference I see from 'info emacs
shell'

yz7502@gmail.com wrote:

If those aliases are not specific to ksh when run under Emacs, then
yes you should define them in the $ENV file. I've used a couple
different approaches to setting ENV in my .profile:

case "$-" in
(*i*) export ENV=$HOME/.kshrc ;;
(*) unset ENV ;;
esac

or:

if [[ -f $HOME/.kshrc ]]; then
export KSHRC=$HOME/.kshrc
export ENV='${KSHRC[(_$-=0)+(_=1)-_${-%%*i*}]}'
fi

William Daffer wrote:

I think this is it.
I did restart emacs, but I don't think I logged out yesterday.

I am very happy to see my aliases after I restarted everything this
morning.

Thank you all.

op132650c@mail.telepac.pt writes:

--- Tim X:

...

(THREE suggestions snipped :)

[...]

I've put setting LS_COLORS under a condition in my .bashrc :

if [ "$EMACS" != "t" ]
then
PS1="$PS1_long"
if [ "$OSVAR" = "Linux" ]; then
LS_COLORS='...[set it to your liking] ...'
export LS_COLORS
else # Darwin: