public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: L A Walsh <cygwin@tlinx.org>
To: cygwin@cygwin.com, smooge@gmail.com, moss@cs.umass.edu,
	       michel.labarre@rogers.com, duncan_roe@optusnet.com.au,
	       cygsimple@gmail.com
Subject: Either trim quoted text or STOP BOTTOM POSTING (was: alias appears to not work...)
Date: Fri, 25 Aug 2017 00:37:00 -0000	[thread overview]
Message-ID: <599F710B.1070306@tlinx.org> (raw)
In-Reply-To: <CANnLRdihpyMjU6NyoFMmxiN3SJ22fAYZVprZknoW+JH1uJUi1w@mail.gmail.com>

<forward>
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. 

</forward>
<replytext>

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
...rest 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 aliases.sh file (which
defines 'include' as well as my common aliases):

in BASH_ENV:
[[ $(type -t include) == function ]] || source $_LOCAL_DIR_/aliases.sh
</replytext>

-linda

<text type=appendix close=eof>
Stephen John Smoogen wrote:
> On 22 August 2017 at 12:45, Eliot Moss <moss@cs.umass.edu> wrote:
>   
>> On 8/22/2017 11:18 AM, Stephen John Smoogen wrote:
>>     
>>> On 22 August 2017 at 10:47, Eliot Moss <moss@cs.umass.edu> 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
>> lines:
>>
>> shopt | grep expand_aliases
>> type -a nawk
>> type -t nawk
>>
>> Regards - Eliot
>>
>>
>> --
>> Problem reports:       http://cygwin.com/problems.html
>> FAQ:                   http://cygwin.com/faq/
>> Documentation:         http://cygwin.com/docs.html
>> Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
>>
>>     
>
> OK I figured it out. I didn't copy the original script correctly.
>
> [ssmoogen@el-7 ~]$ ./x.sh foobar
> Before alias
> expand_aliases on
> ./x.sh: line 4: type: nawk: not found
> After alias
> expand_aliases on
> nawk is aliased to `/usr/bin/awk'
> alias
> Hello World!
> [ssmoogen@el-7 ~]$ cat x.sh
> #!/bin/sh
> 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 ~]$ ./x.sh foobar
> Before alias
> expand_aliases off
> ./x.sh: line 4: type: nawk: not found
> After alias
> expand_aliases off
> ./x.sh: line 9: type: nawk: not found
> ./x.sh: 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:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

  reply	other threads:[~2017-08-25  0:37 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-21 22:30 alias appears to not work inside a called bash script Michel LaBarre
2017-08-21 22:53 ` Eliot Moss
2017-08-21 22:55 ` alias appears to not work inside a called bash scripty Duncan Roe
2017-08-22  1:01   ` Michel LaBarre
2017-08-22 14:31 ` alias appears to not work inside a called bash script Stephen John Smoogen
2017-08-22 14:47   ` Eliot Moss
2017-08-22 15:19     ` Stephen John Smoogen
2017-08-22 16:46       ` Eliot Moss
2017-08-22 18:25         ` Stephen John Smoogen
2017-08-25  0:37           ` L A Walsh [this message]
2017-08-25 14:25             ` Either trim quoted text or STOP BOTTOM POSTING cyg Simple
2017-08-25 16:43               ` Dan Kegel
2017-08-26  6:04               ` convenient trimming of quoted text to make points L A Walsh
2017-08-26 15:26                 ` cyg Simple
2017-09-01  4:54                   ` Duncan Roe
2017-09-01  7:37                     ` Csaba Raduly
2017-09-01 12:38                       ` cyg Simple
2017-08-22 17:08       ` alias appears to not work inside a called bash script cyg Simple
2017-08-22 17:14         ` Eliot Moss
2017-08-22 19:07           ` cyg Simple
2017-08-22 19:11             ` cyg Simple
2017-08-23 19:08               ` Eric Blake

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=599F710B.1070306@tlinx.org \
    --to=cygwin@tlinx.org \
    --cc=cygsimple@gmail.com \
    --cc=cygwin@cygwin.com \
    --cc=duncan_roe@optusnet.com.au \
    --cc=michel.labarre@rogers.com \
    --cc=moss@cs.umass.edu \
    --cc=smooge@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).