How to get 'Normal' (or higher) version of (x86) vim?

[Frank Slootweg via cygwin]

I currently have vim version 8.0.596 from the (x64) package
"vim-8.0.0596-1 - vim: Vi IMproved - enhanced vi editor".

'vi --version' says:

"VIM - Vi IMproved 8.0 (2016 Sep 12, compiled May 12 2017 11:38:40)
 Included patches: 1-596
 Modified by 
 Compiled by 
 Small version without GUI.  Features included (+) or not (-):"

From other threads on this list, I understand that vim should at least
be the 'Normal' version or even the 'Huge' version. Or is that only the
case for the x86_64 package? (I have a 64-bit computer/OS (Windows 8.1),
but - at least for the time being - I would like to keep Cygwin at x86.)

I need some options which are in the 'Normal' version, but not in my
current 'Small' version, specifically 'cryptv' and 'comments'

Is there another or earlier package which I can install to get the
'Normal' (or higher) version of vim?

Thanks in advance for any and all responses.

Frank

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

Re: How to set the colors of terminfo's standout mode?

[Frank Slootweg]

Reini Urban wrote:
 Frank Slootweg schrieb:
A better solution would be one which 1) does *not* hardcode the
  colors, 2) *does* use inverse video (7) and 3) displays
  white-on-black.

 Oh god, this man is insisting.
 The default white color on terms without being able to change faces is
 lightgrey!
 White is used for bold on such stupid terms, which is a more important
 emphasis to have than white.

 Or how to define bold white then?
 Some better terminals, like rxvt, know how to render Courier-Bold or
 Lucida-Bold, but CMD.EXE not.
 Since our default is CMD.EXE and not rxvt, your desiderations (white
 on black) are bogus.

  Well, as my test showed, I *can* do white by bolding (1). The point
is that when combined with inverse/reverse video (7), the background
color is not black but dark-grey. What is your explanation for the
background being dark-grey for inverse/reverse video?

  As to my bogus desiderations, the concept of inverse (or reverse)
video already exists since the seventies (or earlier), and, as I wrote
in my basenote and later reproduced with simple echo(1) commands, Cygwin
B20 has *no* problems with it, so it is not a question of the 'terminal'
(i.e. CMD.EXE in my case) being too limited, but of Cygwin.

  A better solution would be one which 1) does *not* hardcode the
  colors, 2) *does* use inverse video (7) and 3) displays
  white-on-black.

 The only better solution is to use a term (rxvt) which can do this.
 Use TERM=rxvt-cygwin-native then and not TERM=cygwin.

  See above.




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How to set the colors of terminfo's standout mode?

[Frank Slootweg]

  Thanks all for your responses.

  Barry, you have given me a workaround and enabled me to find a second
workaround!

  If people still want to try to find a better solution, I have
'attached' instructions on how to (try to) reproduce the problem.

Barry Buchbinder wrote:
[deleted]
 It is a fact of color: the only difference between grey and white is
 intensity; any white can be made to look grey when compared to a more
 intense white.  What you see as light grey is what was long ago in IBM
 PC land defined as white so that what you want to call white could be
 used for bold.  (Indeed, black can also be relative, being varying
 shades of dark grey, until on gets down to true black (zero photons).)

 The 1 makes the foreground color more intense.  5 should cause
 blinking but may end up making the background color more intense.  Try

 \cygwin\bin\echo -en 'Normal. \033[30;47;5mBlack on
while.\033[0;37;40m Normal again.'

 to get black on white.

  That did not work (Normal. is normal (i.e. black on white), Black
on while. is also normal (black on white) and Normal again. is
lightgrey-on-black and the display stays that way instead of going back
to normal black on white). But not to worry, read on.

 The script in
http://sources.redhat.com/ml/cygwin/2004-04/msg01161.html
 should show you how everything looks on your system.

  (When, as is my 'need', starting with black text on a white
background,) The only combination which shows the desired white-on-black
is 1;37;40 (more about that later). The  7 = reverse video = 30;47 
part is displayed as black-on-lightgrey.

The best I get so far is:
 
  \cygwin\bin\echo -en '\033[37;40mThis is a text.\033[30;0m'
 
Which gives me light-grey (instead of the desired white) text on a
  black (as desired) background.

 Try
 \cygwin\bin\echo -en '\033[1;37;40mThis is a text.\033[30;0m'
 The added 1 bolds the 37, which should turn foreground light-grey
 to real white.

  Thanks! That indeed displays as the desired white-on-black. The
disavantage of this is that it is hardcoded, i.e. for my normal
black-on-white it effectively is 'inverse-video', however for other
normal (non-inverse) colors, it would not be inverse-video, but just
white-on-black. Read on.

  Now that I knew the effect of 1 (bold), I continued with the escape
sequences which I got from Cygwin B20's /etc/termcap entry for cygwin
(= linux): mr=\E[7m:so=\E[7m:se=\E[m

  I came up with:

\cygwin\bin\echo -en '\033[1;7mThis is a text.\033[0m'

which gives white (desired) text on a dark-grey (undesired) background.

  This is my second workaround. It has better contrast than the default
(lightgrey-on-darkgrey), but less contrast than the above hardcoded
white-on-black. The advantage of this workaround is that the colors are
not hardcoded, i.e. I just say bold and inverse video.

  While not ideal, these workarounds will do for now. Now I will have to
get them into a new terminfo entry (Yes, I know how to do that, but have
to install untic and friends, etc..).

What next?
==

  In case anyone wants to try reproduce my problem and then try to find
a better solution:

[FWIW, I have Windows XP (Professional).]

[While I have the problem in a 'DOS', i.e. non-(bash-)shell window, I
will give the procedure for a default bash window, because that is
probably easier.]

- Start with the default bash window [1] that came with Cygwin (in my
  case 1.3.x, since updated to 1.5.9): Start - All Programs - Cygwin
  - Cygwin Bash Shell.

- Temporarily change the forground/background colors: Click on the
  upper-left icon - Properties - Colors - Screen Text to black
  (0/0/0) and Screen Background to white (255/255/255).
  In case it matters, my Font is the default, Raster Fonts with Size
  8 x 12.

- echo -en '\033[7mThis is a text.\033[0m'
  This will probably be lightgrey-on-darkgrey. If so, you have
  reproduced my problem (because I want white-on-black).

- /bin/echo -en '\033[1;37;40mThis is a text.\033[30;0m'
  This will probably be white-on-black, i.e. the hardcoded workaround
  which Barry gave.

- /bin/echo -en '\033[1;7mThis is a text.\033[0m'
  This will probably be white-on-darkgrey, i.e. the second workaround
  which I gave.

  A better solution would be one which 1) does *not* hardcode the
colors, 2) *does* use inverse video (7) and 3) displays
white-on-black.

[1] I.e. the ('DOS') Command Prompt-like window which is started by
the shorcut which executes (Target:) C:\cygwin\cygwin.bat, which
contains:
[Start cygwin.bat:]
@echo off

C:
chdir C:\cygwin\bin

bash --login -i
[End cygwin.bat]





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How to set the colors of terminfo's standout mode?

[Frank Slootweg]

  Thanks, Alejandro and Hannu, for your additional responses.

  I am again getting closer, but still not there. Please bear with me.

  At the time, I did not quite understand this part from Alejandro:

A OK. In my experience, you can set the fg/bg colors the way you want
A by modifying the system settings in the shortcut (right-click on
A window bar and modify properties there), or by using *bold colors* in
A your definitions. For some reason, in the win32 console \e[00;30m is
A grey and \e[01;30m is white.

  Now that I know what these escape sequences mean (thanks to the
document which Alejandro posted and [1]), I understand that part better.

  However, *whatever* I do, I can never get the text/foreground color
white. 37 should do that, but it gives me light-grey instead
(192/192/192 in Selected Color Values of Properties).

  Also Alejandro's escape sequences do not work for me. \e[00;30m gives
me black text on a white background (i.e. no change) and \e[01;30m gives
me light-grey text on a white background. 01 is Bold, so according to
Alejandro that should give me white (text), but it gives me light-grey.

  The best I get sofar is:

\cygwin\bin\echo -en '\033[37;40mThis is a text.\033[30;0m'

  Which gives me light-grey (instead of the desired white) text on a
black (as desired) background.

  I still did not understand why the old (tin) executable on the old
Cygwin B20 release could give white on black, because it seems to be a
pure Win32 console issue.

  B20 apparently used /etc/termcap instead of terminfo (there is no
terminfo directory), but also the B20 /etc/termcap (cygwin = linux)
escape sequences for rev/mr, smso/so and rmso/se give light-grey on
dark-grey (instead of white on black). Those escape sequences were
mr=\E[7m:so=\E[7m:se=\E[m

  However *those* (\E[7m and se=\E[m) escape sequences *do* bring me
closer:

  If I use *those* (\E[7m and se=\E[m) escape sequences with *B20*'s
echo(1) command, I *do* get white (desired) text on black (desired)
background, while with the *new* (1.5.9) echo(1) command, I get
light-grey (undesired) on dark-grey (undesired).

  I.e. in short: With B20 versus 1.5.9 echo(1) commands, I see the
*exact same* behaviour as I see with the B20 versus 1.5.9 tin
executables!

  So it seems that this is not a terminfo problem, but another type of
Cygwin problem and that even something as simple as echo(1) is somehow
'terminal/color aware [2]!

  Anyone any idea *where* those (echo(1) et al related) color settings
can be set? I.e. what makes 1.5.9's echo(1) command display a
white-on-black escape sequence as lightgrey-on-black or lightgrey-on-
darkgrey?

[1] Linux Magazine  September 2003  POWER TOOLS  Escape Sequences Useful
Text that You Can't See:
http://www.linux-mag.com/downloads/2003-09/power/escape_sequences.html

[2] For some reason *DOS* echo, type and copy ... con commands
*display* [3] the escape characters instead of executing them, so I had
to use echo(1). If someone knows a way to let *DOS* commands execute
escape sequences insteas of displaying them, then please let me know.

[3] Where the escape character is displayed as a (1-character)
back-arrow character.





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How to set the colors of terminfo's standout mode?

[Frank Slootweg]

Hannu E K Nevalainen wrote:
  From: [deleted] On Behalf Of Frank Slootweg
 
 FWIW:
 
 $ cat ~/.Xdefaults
 # XTerm == rxvt as rxvt simulates xterm
 
 rxvt.background:black
 rxvt.foreground:grey
 rxvt.visualBell:true
 
 ... I know these things get explained in some man/info-page that I
 currently am too lazy to look up. (man/info rxvt?)

  Note that I am *not* using an X terminal (emulator), but a Command
Prompt 'DOS' window. AFAIK, the X settings do not apply in that case.
Anyway, I do not even have a .Xdefaults file (anywhere) and my
background is white, not black.



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How to set the colors of terminfo's standout mode?

[Frank Slootweg]

Alejandro López-Valencia wrote:
 At 03:05 a.m. 27/04/2004, Frank Slootweg wrote:
Please?
 
 On April 20, I wrote:
 
 How can I set the colors of terminfo's standout (smso, so) mode?
  
 I have a terminfo application (tin, the newsreader) which, as
   far as

 [snip]

 I now rebuilt (configure,/make, compile, link, etc.) the
   application on Cygwin 1.5.9. That new version displays standout
   mode as light-grey text on a dark-grey background, i.e. little
   contrast and very hard to read.
  
 Basically I want the old behaviour (white-on-black) on Cygwin
   1.5.9, but have no idea how/where that can be set.

 Have you read the man page? Particularly the section titled:

  GLOBAL OPTIONS MENU AND TINRC CONFIGURABLE VARIABLES

 where it documents how you can set up screen colors by editing tinrc?
 My knowledge on this topic stops here (I use slrn with jwk patches,
 best offline news reading I've done ever). I just happen to have tin's
 man page in /var/spool/cache/man/cat1 yet [1]).

  Yes, but (AFAIK) the col_* variables apply only if you use a color
'terminal' (i.e. not a mono-chrome (grey tones) one). Anyway,
col_invers_fg was set to white (7) and _bg to blue (4), while the actual
display was light-grey on dark-grey. Changing the _bg to black (0) also
had no effect.

  So I think the standout/'inverse video' colors are set somewhere else,
but I do not know where. That is the problem, and is confirmed by the
fact that tput smso shows the same behaviour. (BTW, the normal,
non-inverse-video, colors for a Command Prompt 'DOS' window are set in
the Properties of that window, but there there are no settings for
inverse-video.)

 Some more information: The application is started from a
   Command Prompt 'DOS' window, i.e. not from a (bash) shell.
   However when I do

 [snip]

 If you are running in a plain Windows console with command.com or
 cmd.exe as shell, you should not set TERM to cygwin but to something
 more appropriate such as 'pccons'. Heck, anything in
 /usr/share/terminfo/p/ with a name starting on 'pc' would be more
 appropriate.

  pccons gives an error:

 tin: Terminal must have clear to end-of-screen (cd)
 tin: Screen initialization failed

  The README.WIN file which comes with tin instructs to use pcansi,
which  gives the same effect (light-grey on dark-grey) as cygwin. (I can
not remember where I got the cygwin setting from.).

[deleted]

 [1] BTW, there is already an official binary of tin you can download
 from the mirrors with setup.exe. Unless you are using the latest
 unstable, of course...

  Yes, I am aware of that, but thanks anyway. I won't bother you with my
reasons for wanting to build tin myself.

  So anyone any other suggestions?




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How to set the colors of terminfo's standout mode?

[Frank Slootweg]

Alejandro López-Valencia wrote:
 At 04:33 a.m. 28/04/2004, Frank Slootweg wrote:
So I think the standout/'inverse video' colors are set somewhere
  else, but I do not know where. That is the problem, and is confirmed
  by the fact that tput smso shows the same behaviour. (BTW, the
  normal, non-inverse-video, colors for a Command Prompt 'DOS'
  window are set in the Properties of that window, but there there are
  no settings for inverse-video.)

 Gotcha. I missed that part.

 OK. In my experience, you can set the fg/bg colors the way you want by
 modifying the system settings in the shortcut (right-click on window
 bar and modify properties there), or by using *bold colors* in your
 definitions. For some reason, in the win32 console \e[00;30m is grey
 and \e[01;30m is white.

  Getting closer! As I mentioned, Properties has no settings for
inverse-video and bold colors (I assume you mean the colors of bold
fonts) did not help, but ... :

  (In combination with tput smso,) I get black for \e[00;30m and white
for \e[01;30m (remember that my 'DOS' window is black-on-white, so
opposite from a normal Cygwin bash window). So with these kinds of
escape sequences I *do* seem to have some kind of control over the
colors, I just do not have the *right* colors yet.

  Is there a place where all these (I assume ANSI) escape sequences for
colors are listed? When I have that information, I can probably untic an
existing terminfo entry, modify it and tic it back to another name and
use that.






--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: How to set the colors of terminfo's standout mode?

[Frank Slootweg]

  Please?

On April 20, I wrote:

   How can I set the colors of terminfo's standout (smso, so) mode?

   I have a terminfo application (tin, the newsreader) which, as far as
 I can tell, uses standout mode to highlight things.

   I first used this on the old Cygwin B20 release and that gave white
 text on a black background (normal text is black on white), i.e.
 'inverse-video' and a good contrast, i.e. easy to read.

   I now rebuilt (configure,/make, compile, link, etc.) the application
 on Cygwin 1.5.9. That new version displays standout mode as light-grey
 text on a dark-grey background, i.e. little contrast and very hard to
 read.

   Basically I want the old behaviour (white-on-black) on Cygwin 1.5.9,
 but have no idea how/where that can be set.

   Some more information: The application is started from a Command
 Prompt 'DOS' window, i.e. not from a (bash) shell. However when I do
 a tput smso in that window and then echo text, I see the same
 behaviour (light-grey on dark-grey), so I think it is a terminfo/
 terminal issue, not a shell issue. The TERM variable is set to
 cygwin.

   Thanks in advance for any and all responses.




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

How to set the colors of terminfo's standout mode?

[Frank Slootweg]

  How can I set the colors of terminfo's standout (smso, so) mode?

  I have a terminfo application (tin, the newsreader) which, as far as
I can tell, uses standout mode to highlight things.

  I first used this on the old Cygwin B20 release and that gave white
text on a black background (normal text is black on white), i.e.
'inverse-video' and a good contrast, i.e. easy to read.

  I now rebuilt (configure,/make, compile, link, etc.) the application
on Cygwin 1.5.9. That new version displays standout mode as light-grey
text on a dark-grey background, i.e. little contrast and very hard to
read.

  Basically I want the old behaviour (white-on-black) on Cygwin 1.5.9,
but have no idea how/where that can be set.

  Some more information: The application is started from a Command
Prompt 'DOS' window, i.e. not from a (bash) shell. However when I do a
tput smso in that window and then echo text, I see the same
behaviour (light-grey on dark-grey), so I think it is a terminfo/
terminal issue, not a shell issue. The TERM variable is set to cygwin.

  Thanks in advance for any and all responses.




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: ssmtp 2.38.7-4 reads headers from message body.

[Frank Slootweg]

Corinna Vinschen [EMAIL PROTECTED] wrote:
 On Sat, Oct 18, 2003 at 09:08:48PM +0200, Frank Slootweg wrote:
Anything else you need?

 Your /etc/ssmtp/ssmtp.conf file would be interesting.

  Here it is (wrapped (at 72 columns) by OE):

#
# /etc/ssmtp.conf -- a config file for sSMTP sendmail.
#
# The person who gets all mail for userids  10
root=postmaster
# The place where the mail goes. The actual machine name is required
# no MX records are consulted. Commonly mailhosts are named
mail.domain.com
# The example will fit if you are in domain.com and you mailhub is so
named.
mailhub=smtp.cablewanadoo.nl
# Where will the mail seem to come from?
rewriteDomain=wanadoo.nl
# The full hostname
hostname=ipc1fs02.wanadoo.nl
# Set this to never rewrite the From: line (unless not given) and to
# use that address in the from line of the envelope.
FromLineOverride=YES




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: ssmtp 2.38.7-4 reads headers from message body.

[Frank Slootweg]

Corinna Vinschen [EMAIL PROTECTED] wrote:
 On Fri, Oct 17, 2003 at 04:46:13PM +0200, Frank Slootweg wrote:
  Corinna Vinschen [EMAIL PROTECTED] wrote:
   On Fri, Oct 17, 2003 at 03:30:39PM +0200, Frank Slootweg wrote:
  [deleted]
  So my problem is solved, but what about the generic problem?
IMO ssmtp in a Cygwin environment should be able to handle DOS
format data. AFAIK, there are (POSIX? XPG?) standards for
opening a stream in text mode, which should make things
compatible between ('DOS' and UNIX) platforms.
  [...]
   So I think that ssmtp is somewhat unique and somewhat 'broken'.

 I've took some time to investigate the situation and I have to say
 that I can't reproduce your effect.  I created an appropriate testfile
 from your template and regardless of having the file on a textmode
 mount or a binmode mount, regardless of the shell in which I call
 `ssmtp -t  file' and regardless if the file has LF or CRLF
 lineendings, ssmpt always got that right.  Especially I found that
 ssmtp already opens the file in textmode (yeah, I didn't remember) so
 the problem you found is even more weird.  Which means, I'll not
 change anything unless somebody (you?) can explain what *exactly* goes
 wrong.

  Thanks for your efforts.

  To be Frank :-), I am not aware that I have any special kind of
'mount'. I understand what you mean, but I have just a basic Cygwin
setup on my C: drive. The only related thing I can think of is that I
always specify Default Text File Type as Unix when I run Cygwin
Setup (I don't know what that does, but that is what I specify).

  In my normal setup, tin is invoked from a DOS Command Prompt window
(i.e. not from bash) and tin invokes ssmtp as indicated in my
'basenote'. However after your posting, I tried in a bash shell and can
also reproduce the problem there:

$ /usr/sbin/ssmtp -t .letter.save
/usr/sbin/ssmtp: smtp server didn't accept RCPT To: command, replied
450 [EMAIL PROTECTED]: Sender address rejected: Domain not
found.

[EMAIL PROTECTED] ~
$

  The [EMAIL PROTECTED] address is only in the body, so ssmtp
clearly gets the address from the body.

  To show that it is really the DOS-format which is the problem:

$ cat .letter.save | /usr/sbin/ssmtp -t
/usr/sbin/ssmtp: smtp server didn't accept RCPT To: command, replied
450 [EMAIL PROTECTED]: Sender address rejected: Domain not
found.

  Using cat(1) and a pipe to show that the problem is not related to 
input redirection.

[EMAIL PROTECTED] ~
$ cat .letter.save | tr -d '\015' | /usr/sbin/ssmtp -t

[EMAIL PROTECTED] ~
$

  I.e. without \r (\015), ssmtp works correctly.

  Anything else you need?

  It would be interesting to hear if other people can reproduce my
problem.














--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: ssmtp 2.38.7-4 reads headers from message body.

[Frank Slootweg]

Yesterday, I wrote:

   Of course ssmtp should only use the From: line from the header, not
 from the body. Suppose the body contained for example From:
 [EMAIL PROTECTED]. We would not want the message to be sent
 with that From: line, do we? :-)

   I did some more testing and found that ssmtp does apparently *not*
 use the To: line from the body. That would of course be even worse.

  Well, things *are* worse. Apparently ssmtp uses From: *and* To: from
the body, but just not the way I thought.

  I did another test with four addresses, From: and To: in the header
(FH and TH) and From: and To: in the body (FB and TB). ssmtp uses them
as follows (when using the -t option):

FH: OK, mail is sent with this From: address.
TH: OK, mail is sent to   this To:   address.

FB: Wrong, this address is set in a Return-Path: header (with uppercase
downcased).
TB: Wrong, mail is *also* sent to this address and shown in an
Apparently-To: header.

  I hope we all agree that processing FB and TB is totally wrong. The
body should not be interpreted in any way and mailing to TB is pretty
annoying and potentially dangerous and mailing with a Return-Path: set
to FB is misrepresenting the real sender.

  In hindsight, I probably agree with Felix van Hove that -t is not
supported, because while ssmtp does not complain about -t, it says
this when using -ba:

 /usr/sbin/ssmtp: -ba is not supported by sSMTP sendmail, nor is -t.

  OTOH, I also tried to use
-FFrank Slootweg [EMAIL PROTECTED] [EMAIL PROTECTED]
instead of -t. That works a little better because it does not send the
message to TB, but it still sets FB in a Return-Path: header, which is
really wrong.

  When using -d9 (debugging) you can see that ssmtp says Read
Header: when reading the *body* (both with -t and with -F... -f...
address).

  Does anybody have some other suggestions? Another tool which can do
the same job (i.e. read From:, To:, Subject: (and possibly Cc: and Bcc:)
only from the header part of the input file)?










--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: ssmtp 2.38.7-4 reads headers from message body.

[Frank Slootweg]

Corinna Vinschen [EMAIL PROTECTED] wrote:
 On Fri, Oct 17, 2003 at 12:08:40PM +0200, Corinna Vinschen wrote:
  On Fri, Oct 17, 2003 at 11:04:19AM +0100, Sam Edge wrote:
   Corinna Vinschen [EMAIL PROTECTED] wrote in
   [EMAIL PROTECTED]
   in gmane.os.cygwin on Fri, 17 Oct 2003 11:33:07 +0200:
  
I'm not familar with the mail-related RFCs.  Is
it allowed to send lines with DOS lineendings?
  
   The RFCs for SMTP e-mail (RFC2821 and its predecesors) /require/
   CR-LF (\r\n i.e. DOS) line endings. (Probably because
   debugging using dumb terminals or printers was easier that way in
   days of yore.)
 
  Interesting.  So a check as in ssmtp:
 
while ((fgets (buffer, sizeof buffer, stdin) != NULL) 
(buffer[0] != '\n'))
  {
/* It's a header line */
  }
 
  seems a bit oversimplified, right?

 Well, this happens when reading the input file.  When writing the
 output stream to the mailhub, it uses \r\n explicitely.

 So ssmtp assumes that the input file is using only \n.  Of course,
 ssmtp has never been written with textmode mounts in mind...

  Thanks! That is it! I converted the input file from DOS (\r\n) to UNIX
(\n) format and now ssmtp works correctly, i.e. it only reads From: and
To: from the header, not from the body. So now I only have to
incorporate this conversion into my tin (newsreader) setup.

  So my problem is solved, but what about the generic problem? IMO ssmtp
in a Cygwin environment should be able to handle DOS format data. AFAIK,
there are (POSIX? XPG?) standards for opening a stream in text mode,
which should make things compatible between ('DOS' and UNIX) platforms.
Anyway, even if ssmtp is supposed to be 'UNIX-only', then why can it
(apparently) handle DOS format lines *in* the header and *in* the body,
but not *between* the header and body?

  What happens now? Do the author(s)/maintainer(s) of ssmtp pick up this
issue? The Cygwin Where should I send problem reports? page
(http://cygwin.com/problems.html) requests not to send bug reports
directly to the author(s)/maintainer(s), but will they really pick up
bug reports from this high volume mailing list ([EMAIL PROTECTED])?







--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: ssmtp 2.38.7-4 reads headers from message body.

[Frank Slootweg]

Olaf Foellinger [EMAIL PROTECTED] wrote:
 On Fri, Oct 17, 2003 at 10:57:27AM +0200, Frank Slootweg wrote:
 
Does anybody have some other suggestions? Another tool which can
  do the same job (i.e. read From:, To:, Subject: (and possibly Cc:
  and Bcc:) only from the header part of the input file)?

 exim ?

  Thanks for the pointer!

  As you can see in my other response, I already have a usable
workaround for ssmtp (convert DOS-format input to UNIX-format), but exim
may come in handy at some time. I installed it and played a little with
it. Even without bothering to configure it, it 'automagically' worked,
but then stopped working with mail stuck in the mail queue. As I have
too litlle experience with sendmail (I only used it as a user, i.e.
sendmail -t, not as an admin), it is not clear to me if I can only use
exim -t inputfile or that I also have to run exim (with -bd?) as a
daemon. Anyway, that is for the future. For the moment I can use ssmtp
with UNIX-format input. But thanks again for your pointer!






--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: ssmtp 2.38.7-4 reads headers from message body.

[Frank Slootweg]

Corinna Vinschen [EMAIL PROTECTED] wrote:
 On Fri, Oct 17, 2003 at 03:30:39PM +0200, Frank Slootweg wrote:
[deleted]
So my problem is solved, but what about the generic problem? IMO
  ssmtp in a Cygwin environment should be able to handle DOS format
  data. AFAIK, there are (POSIX? XPG?) standards for opening a stream
  in text mode, which should make things compatible between ('DOS' and
  UNIX) platforms.

 Nope, that won't work as a generic solution.  Think binary
 attachment.

  Sorry, but I do not agree. In a mail message (i.e. header(s) and
body/bodies), a binary attachment is not really binary. It is encoded
as 'text' (i.e. uuencode, base64, etc.) and those text lines can have a
normal text end-of-line, i.e. \r\n for 'DOS' and \n for UNIX.

[deleted]

 Erm... are you reading the cygwin announcements?

  No, I don't. Can you give a pointer where/how I can read the cygwin
announcements? Thanks.

 I'm ssmtp maintainer
 for Cygwin but there's no upstream maintainer. ssmtp development has
 been abandoned.  Since you're the first one coming across that problem
 I don't value it too high, especially since there's a workaround.
 And I'm not sure if that's actually a ssmtp problem or if that's not
 rather a tin problem.  Yes, I'm also tin maintainer for Cygwin...

  You would have to ask Urs et al whether or not this is a tin problem.
As shown in my 'basenote', I originally posted about this in the
news.software.readers Newsgroup. I'll report my findings there.
Personally I consider it normal that under Windows, tin will write
DOS-format text files (because some generic Windows stuff (for example
notepad) still has problems with UNIX-format). Until now most 'free'
software has been very transparent with regard to DOS and UNIX format
text. Case in point: I used to do most of my text stuff on UNIX systems
(at work). Now I'm doing most on my (private) Windows system. Most of my
old files are still UNIX format, but give no problems. So I think that
ssmtp is somewhat unique and somewhat 'broken'.

 Before I forget it:  PATCHES GRATEFULLY ACCEPTED!

  Don't hold your breath. I have only very limited programming
experience and none in a Cygwin environment, so this will probably be
too hard for me to patch.







--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

ssmtp 2.38.7-4 reads headers from message body.

[Frank Slootweg]

[This is my first posting to this list. I hope the format is OK.]

  I am trying to use ssmtp (2.38.7-4) as my 'mailer' in tin, the
newsreader. tin invokes ssmtp as

/usr/sbin/ssmtp -t  %F

where %F is a file which contains the header (lines), a blank line (only
\r\n) and body.

  I have found that apparently ssmtp keeps reading 'header' lines (like
From:, etc.) *after* it has read the full header, i.e. it also reads
'header' lines from the *body* of the message. For example it will fail
(on the From: Frank Slootweg [EMAIL PROTECTED] line in the
*body*) with the below input file.

  Of course sending a message which contains a header in the body is
quite common, so at the moment I can not use ssmtp.

  Is this a known problem? Any solutions/workarounds/etc. (other than
'manually' quoting () the header lines in the body)?

  Thanks in advance for any and all responses.

[start example input file:]
From: Frank Slootweg [EMAIL PROTECTED]
To: Frank Slootweg [EMAIL PROTECTED]
Subject: ssmtp test

-- forwarded message --
From: Frank Slootweg [EMAIL PROTECTED]
Subject: Re: [tin +OE ] Use OE to mail from tin?
Newsgroups: news.software.readers
References: [EMAIL PROTECTED]
Organization: NOYB
Date: 11 Oct 2003 19:42:24 GMT
Message-ID: [EMAIL PROTECTED]

  Thanks, Dirk and Urs. I probably first will have a look at the Cygwin
ssmtp package. In hindsight, it probably isn't fair on tin to ask it to
invoke OE. It is already sad that it 'has' to *run on* a virus, but
asking it to willingly *invoke* one is plain cruel. My apologies! [1]

[1] For the HI: :-)
-- end of forwarded message --
[end example input file.]

[Note: I am sending this with OE, which may and may not correctly
preserve the blank line (^\r\n$) between the header and body. Of course
I have tested things with a correct blank line.]



--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: ssmtp 2.38.7-4 reads headers from message body.

[Frank Slootweg]

[I hope this reply is threaded correctly. The digest version of this
list does not preserve References: etc.. I got a copy of your message
from the archive and used ssmtp :-) to send it to myself (in OE).]

Corinna Vinschen [EMAIL PROTECTED] wrote:
 On Thu, Oct 16, 2003 at 10:35:59AM +0200, Frank Slootweg wrote:
  [This is my first posting to this list. I hope the format is OK.]
 
I am trying to use ssmtp (2.38.7-4) as my 'mailer' in tin, the
  newsreader. tin invokes ssmtp as
 
  /usr/sbin/ssmtp -t  %F
 
  where %F is a file which contains the header (lines), a blank line
  (only \r\n) and body.
 
I have found that apparently ssmtp keeps reading 'header' lines
  (like From:, etc.) *after* it has read the full header, i.e. it also
  reads 'header' lines from the *body* of the message. For example it
  will fail (on the From: Frank Slootweg [EMAIL PROTECTED]
  line in the *body*) with the below input file.

 More input.  What means fail?  What is ssmtp doing with the mail?
 Reading too much doesn't sound very desctructive to me.

  Sorry for not being clearer.

  With the example, ssmtp failed, i.e. it did not send a message.

  It should not have failed, but it failed because it used the (second)
From: line from the *body*, and that From: line was invalid (From:
Frank Slootweg [EMAIL PROTECTED]. It *should* have sent the
message to the From: line in the *header* (From: Frank Slootweg
[EMAIL PROTECTED]).

  The failure message was:

 /usr/sbin/ssmtp: smtp server didn't accept RCPT To: command, replied
 450 [EMAIL PROTECTED]: Sender address rejected: Domain not
found.

(I don't know why the failure message says RCPT To: instead of
From:.)

  Of course ssmtp should only use the From: line from the header, not
from the body. Suppose the body contained for example From:
[EMAIL PROTECTED]. We would not want the message to be sent
with that From: line, do we? :-)

  I did some more testing and found that ssmtp does apparently *not* use
the To: line from the body. That would of course be even worse.

  I hope this explains the problem better.




--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/

Re: ssmtp 2.38.7-4 reads headers from message body.

[Frank Slootweg]

Felix van Hove [EMAIL PROTECTED] wrote:

 -t isn't supported, see man ssmtp.

 I have no problem to forward your message without this option, same
 ssmtp version 2.38.7.

  I beg to differ (that -t isn't supported). (Of course) I have looked
into this in detail before I posted.

  The SSMTP(8) manpage says:

 OPTIONS
Most sendmail options are irrelevent to sSMTP. Those marked
``ignored'' or ``default'' have no effect on mail transfer.
Those marked ``unsupported'' are fatal errors.  Those marked
``simulated'' are not errors, but the result is for the
program to exit with an informative message. A sort of fatal
non-error.

  I.e. an unsupported option should give a fatal error, but -t does
*not* give a fatal error if the From: address in the body is correct.

  Also the manual page says:

 -t Read   message, searching for recipients. ``To:'', `Cc:'', and
``Bcc:'' lines will be scanned for people to send to. Any
addresses in   the  argument list will be suppressed (not sup-
ported).

  For all other options, (unsupported) is listed *directly after* the
option, i.e. for example:

  -bd(unsupported) Run as a daemon.

  For the -t option it is listed at the *end* (and, to nit-pick, says
not supported, not unsupported). I take it to mean that it only
applies to the last sentence (Any addresses in the argument list will
be suppressed).

  My tests prove my thinking, i.e. -t *is* processed. However ssmtp
should not interpret the body of the message in any way (i.e. it should
not interpret any From: line in the body), it should just send it.





--
Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
Problem reports:   http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ:   http://cygwin.com/faq/