This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Either trim quoted text or STOP BOTTOM POSTING (was: alias appears to not work...)

If you can't trim your quoted text, then please stop burying the
new stuff on the bottom.

Some people expect to be able to read every email like a separate
book --- with everything in the topic included in EACH email.  This
is just abusive because they demand that everyone put things in
"book" order with newest stuff last.
If you think about it, in normal face-to-face interactions, don't
most people consider it rude when someone jumps into the middle
of a conversation and and wants a people to stop the conversation
and repeat the previous stuff so they can be brought up to speed?
Isn't that a bit wasteful of the groups time?

So why would people think it normal to include all the text from
a thread/subject just so people won't have to read previous emails?

If I enter a thread, and am going to respond to something, I try
to read the previous few notes in the chain to see what is being
responded to.

I've noticed it is most often bottom-poster who include all
previous quotes -- and that's the worst -- having to WADE
through EVERYTHING that came before, when EVERYONE on the
list has already received it.  That's the rub: if you
want to bottom-post, then trim what you are quoting to that
which is necessary (and that's fine w/me).
But if you are not good about trimming, then put the *IMPORTANT*
stuff first (your NEW text).  That's write -- the most important
thing in your email is what YOU are writing.  It should come
first.  If you feel a need to quote large parts of the previous
conversation, put it in an appendix -- because most people will
have already received and read it.  Including it again is
"superfluous", but that's why there are appendices.

I DO pay attention to the subject BTW.

I use aliases in many
of my scripts.  I even have an "include" file I use to include
nearly all possible alias I might use, that I can include with:

"include stdalias"  (similar to sourcing it, but with enhancements)

But most don't have my 'include' setup (which is slightly complicated),
so for standalone scripts that I might want to export, I'll
put in a short prefix-stanza, like:

shopt -s expand_aliases
alias my=declare array=my\ -a  int=my\ -i  hash=my\ -A of script that uses 'my' instead of declare or local (they
are equivalent except local can't be used outside of a 'sub'),
and a few type-specific aliases for int's arrays and hashes,
so I can declare them like:

my foo=bar
int isint=1
hash myhash=([one]=1 [two]=2)
array myarray=(zero one two)  # not strictly necessary as
   # 'int' and 'hash' are.  Showing them using 'my -p':

 my -p foo isint myhash myarray          # (shows:)
declare -- foo="bar"
declare -i isint="1"
declare -A myhash=([two]="2" [one]="1" )
declare -a myarray=([0]="zero" [1]="one" [2]="two")

I find they make the code more legible and maintainable.

FWIW, I use BASH_ENV to make sure my aliases are read in, which
uses whether or not 'include' is already defined as an indicator
of whether or not I need to re-read my file (which
defines 'include' as well as my common aliases):

[[ $(type -t include) == function ]] || source $_LOCAL_DIR_/


<text type=appendix close=eof>
Stephen John Smoogen wrote:
On 22 August 2017 at 12:45, Eliot Moss <> wrote:
On 8/22/2017 11:18 AM, Stephen John Smoogen wrote:
On 22 August 2017 at 10:47, Eliot Moss <> wrote:
On 8/22/2017 10:31 AM, Stephen John Smoogen wrote:
It's a *bash* default - it has nothing to do with Cygwin as distinct
from other bash installations.  If you had a different experience
elsewhere, it could be that the default was overridden in some system
wide bashrc file - but that strikes me as unlikely.  I suspect that
this is done as a security measure, to prevent an alias from introducing
a surprise.

I checked on CentOS and there is no shopt option set in any of the
/etc/ files. It must be a compiled in default of some sort as EL6 and
EL7 both work without an explicit `shopt -s expand_aliases`. I then
tried on an Ubuntu 16.04 system and it works without the `shopt -s
expand_aliases` also.

I didn't have access to anything else at the moment so I can't say
which other systems might actually follow the default other than
Cygwin at the moment.
Hmmm ... One of my servers runs EL7 and it works there exactly as under
Cygwin on my laptop.  I wonder: Is there an nawk installed somewhere
on your path on these CentOS and EL* systems?  Put another way, if you
put 'type -a nawk' in your script *before* the alias lines, what output
do you get?  And what about shopt?  I added these lines before the alias

shopt | grep expand_aliases
type -a nawk
type -t nawk

Regards - Eliot

Problem reports:
Unsubscribe info:

OK I figured it out. I didn't copy the original script correctly.

[ssmoogen@el-7 ~]$ ./ foobar
Before alias
expand_aliases on
./ line 4: type: nawk: not found
After alias
expand_aliases on
nawk is aliased to `/usr/bin/awk'
Hello World!
[ssmoogen@el-7 ~]$ cat
echo "Before alias"
shopt | grep expand_aliases
type -a nawk
type -t nawk
alias nawk='/usr/bin/awk'
echo "After alias"
shopt | grep expand_aliases
type -a nawk
type -t nawk
nawk '{print $0}' $*

Change that #!/bin/sh to #!/bin/bash

[ssmoogen@el-7 ~]$ ./ foobar
Before alias
expand_aliases off
./ line 4: type: nawk: not found
After alias
expand_aliases off
./ line 9: type: nawk: not found
./ line 11: nawk: command not found

So when you use bourne sh compatibility aliases get expanded. When you
don't.. they do as the reporter says.

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]