Putty:strange formatting in window output using command file

[poly...@gmail.com]

We have a bunch of different log files on various servers that need
watching, so I created an app to take in the various parameters
(server, log name, location on server), create a command file, and then
start putty and pass it the command file using the -m switch. The
commands run, but the output in the command window is all run together
as if <CR> was replaced with <TAB>. Any ideas on what is happening? A
typical command could be as simple as "ls"

I'm running PuTTy release 0.53b on WinXP, the servers are UNIX/Linux

Thanks in advance,
Sabrina

[JohnK]

Just a guess but the putty command is running non-interactively so the
TERM variable isn't set. You could try adding the -t switch for putty or
explicitly setting the TERM variable within your command file.

Any reason you are running an old version?

JohnK

[poly...@gmail.com]

JohnK wrote:
> Just a guess but the putty command is running non-interactively so the
> TERM variable isn't set. You could try adding the -t switch for putty or
> explicitly setting the TERM variable within your command file.
>
> Any reason you are running an old version?

Sheer inertia ;-) I'll try the latest.
Neither -t nor -T had any effect on the output, but thanks for the
suggestion. It's very puzzling, since the actual command that shows up
in the Linux process looks completely innocuous (and if entered in a
regular interactive Putty window, runs fine).

[Jacob Nevins]

poly...@gmail.com writes:
>start putty and pass it the command file using the -m switch. The
>commands run, but the output in the command window is all run together
>as if <CR> was replaced with <TAB>. Any ideas on what is happening? A
>typical command could be as simple as "ls"

My first guess would be that because you are running a command rather
than interactively, a pseudo-terminal is not being allocated, and so
line discipline options relating to the interpretation of line feeds are
not being applied.

That doesn't quite match the symptoms you describe, but I'm not sure I
entirely understand your description. Does the output look like this?:
<http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter4.html#config-crlf>

If so, I think that's your problem, and enabling that option should fix
it.

>I'm running PuTTy release 0.53b on WinXP, the servers are UNIX/Linux

0.53b has several major known security holes. Upgrade to at least 0.57.
(0.58 is the latest.)

[poly...@gmail.com]

Jacob Nevins wrote:

> My first guess would be that because you are running a command rather
> than interactively, a pseudo-terminal is not being allocated, and so
> line discipline options relating to the interpretation of line feeds are
> not being applied.
>
> That doesn't quite match the symptoms you describe, but I'm not sure I
> entirely understand your description. Does the output look like this?:
> <http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter4.html#config-crlf>
>
> If so, I think that's your problem, and enabling that option should fix
> it.

The output looks exactly like the sample in the link you provided.
Now, the trick is to get the command line to accept the "implicit LF in
every CR" setting. There does not appear to be a command-line flag for
this, and I'd rather stay away from requiring a named session to be
invoked since the tool I'm using is for the whole team not just me.
Also, I am curious why, if the "implicit LF" is NOT set in my session
profiles for a dynamic putty window the output looks correct--since the
tool is accessing the same server.

[poly...@gmail.com]

Jacob Nevins wrote:

> My first guess would be that because you are running a command rather
> than interactively, a pseudo-terminal is not being allocated, and so
> line discipline options relating to the interpretation of line feeds are
> not being applied.
>
> That doesn't quite match the symptoms you describe, but I'm not sure I
> entirely understand your description. Does the output look like this?:
> <http://the.earth.li/~sgtatham/putty/0.58/htmldoc/Chapter4.html#config-crlf>
>
> If so, I think that's your problem, and enabling that option should fix
> it.

The output looks exactly like the sample in the link you provided.