On Sun, 2022-12-11 at 22:29 +, debian-u...@howorth.org.uk wrote:
>
>
> The important bit of my email was actually the bit you've omitted :)
Apologies, I believe it's proper netiquette to trim email posts to the
most relevant of parts. It makes it much better for the archive.
Here is what t
> On Sun, 2022-12-11 at 21:22 +, debian-u...@howorth.org.uk wrote:
> >
> > You're misunderstanding what Greg's saying, again. He's not saying
> > you were given working solutions three times, he's saying you were
> > told at least three times that echo without -n will always produce
> > a newl
On Sun, 2022-12-11 at 21:22 +, debian-u...@howorth.org.uk wrote:
>
>
> You're misunderstanding what Greg's saying, again. He's not saying you
> were given working solutions three times, he's saying you were told at
> least three times that echo without -n will always produce a newline.
I bel
> On Sun, 2022-12-11 at 12:48 -0500, Greg Wooledge wrote:
> > On Sun, Dec 11, 2022 at 11:48:23AM -0500, Jim Popovitch wrote:
> > > On Sun, 2022-12-11 at 08:54 -0500, Greg Wooledge wrote:
> > > > On Sun, Dec 11, 2022 at 08:16:35AM +0100, to...@tuxteam.de
> > > > wrote:
> > > > > That said. Gre
On Sun, Dec 11, 2022 at 02:03:59PM -0500, Jim Popovitch wrote:
>
>
> On Sun, 2022-12-11 at 18:53 +0100, to...@tuxteam.de wrote:
> > On Sun, Dec 11, 2022 at 11:48:36AM -0500, Jim Popovitch wrote:
> > > Ahh, sorry for using a descriptive acronym that I have used for decades
> > > to define an end-
On Sun, 2022-12-11 at 11:46 -0700, Charles Curley wrote:
> On Sun, 11 Dec 2022 11:48:36 -0500
> Jim Popovitch wrote:
>
> > Ahh, sorry for using a descriptive acronym that I have used for
> > decades to define an end-of-line. Whether it's in-fact a CR/LF, or
> >
On Sun, 2022-12-11 at 18:53 +0100, to...@tuxteam.de wrote:
> On Sun, Dec 11, 2022 at 11:48:36AM -0500, Jim Popovitch wrote:
>
> [...]
>
> > Ahh, sorry for using a descriptive acronym that I have used for decades
> > to define an end-of-line. Whether it's
On Sun, 2022-12-11 at 12:48 -0500, Greg Wooledge wrote:
> On Sun, Dec 11, 2022 at 11:48:23AM -0500, Jim Popovitch wrote:
> > On Sun, 2022-12-11 at 08:54 -0500, Greg Wooledge wrote:
> > > On Sun, Dec 11, 2022 at 08:16:35AM +0100, to...@tuxteam.de wrote:
> > > > That said. Greg, I was also shaken by
On Sun, 11 Dec 2022 11:48:36 -0500
Jim Popovitch wrote:
> Ahh, sorry for using a descriptive acronym that I have used for
> decades to define an end-of-line. Whether it's in-fact a CR/LF, or
> just a LF, doesn't really change the original question about the
> addition o
On Sun, Dec 11, 2022 at 12:53:50PM -0500, Greg Wooledge wrote:
[...]
> When echo is operating in SysV mode, the \c escape sequence suppresses
> the generation of a newline.
Woah. I didn't know about that one. Did I say I learn from your
postings every time?
Thanks
--
t
signature.asc
Descript
But
> >when the OP is complaining of an "extra CR/LF" [sic], but is using
> >echo to produce the extra newline himself, well... there you have it.
>
> Now which cases, besides when the -n option is given (I don't know,
> off the bat, I must admit).
The
On Sun, Dec 11, 2022 at 11:48:36AM -0500, Jim Popovitch wrote:
[...]
> Ahh, sorry for using a descriptive acronym that I have used for decades
> to define an end-of-line. Whether it's in-fact a CR/LF, or just a LF,
> doesn't really change the original question [...]
No, but i
On Sun, Dec 11, 2022 at 11:48:23AM -0500, Jim Popovitch wrote:
> On Sun, 2022-12-11 at 08:54 -0500, Greg Wooledge wrote:
> > On Sun, Dec 11, 2022 at 08:16:35AM +0100, to...@tuxteam.de wrote:
> > > That said. Greg, I was also shaken by your roaring tone.
> >
> > Yeah, well, he was told the same thi
he use of echo with variable arguments is therefore strongly
>discouraged.
Again, illustration:
tomas@tritzki:~$ TEST="-n o n o"
tomas@trotzki:~$ echo ${TEST}
=> o n o
(with no newline at its end)
> 3) echo usually, but not always, adds an additional newline chara
Jim Popovitch writes:
> Ahh, sorry for using a descriptive acronym that I have used for decades
> to define an end-of-line. Whether it's in-fact a CR/LF, or just a LF,
> doesn't really change the original question about the addition of a end-
For me - changes. I was confuse
d? This is about running cmds
> > from Debian 11 to Debian 11.
>
> Because you originally asked about a CR/LF (carriage return, and line
> feed) sequence. That is a Windows end-of-line indicator. Linux indicates
> end of line with LF only. Macs, I believe, use CR only. So you bro
some guy who got tripped up
by the nuanced differences between LF and CR/LF. Still, the best info
did came from you Greg, eventually, but it's the same email that Tomas
is questioning your roaring tone. So was your roaring toned email, where
you provided the helpful answer, the cause of you
On Sun, Dec 11, 2022 at 07:04:37AM -0700, Charles Curley wrote:
>
> Because you originally asked about a CR/LF (carriage return, and line
> feed) sequence. That is a Windows end-of-line indicator. Linux indicates
> end of line with LF only. Macs, I believe, use CR only.
Mac OS 9 and
On Sat, 10 Dec 2022 23:16:12 -0500
Jim Popovitch wrote:
> > There is still no CR. At all. Ever. This is not Microsoft
> > Windows.
>
> Why would you assume Windows is involved? This is about running cmds
> from Debian 11 to Debian 11.
Because you originally asked ab
aged.
3) echo usually, but not always, adds an additional newline character to
the output. In most cases, this is acceptable, even preferable. But
when the OP is complaining of an "extra CR/LF" [sic], but is using
echo to produce the extra newline himself, well... there you have
On Sun, Dec 11, 2022 at 12:02:59AM -0500, Jim Popovitch wrote:
[...]
> welp.
>
> Hope you have a good day tomorrow,
To be fair, Greg takes those things seriously. And is extremely helpful,
see his writeups [1]. Recommended reading.
And he has the sharpest eyes around here in things shell.
I t
On Sat 10 Dec 2022 at 23:16:12 (-0500), Jim Popovitch wrote:
> The following
> will add a CR/LF:
>
> TEST=`ssh -o LogLevel=QUIET -t user@server "echo -n ''"`; echo ${TEST}
>
> Using -n on the 2nd echo would remove a necessary CR/LF on any remote
> cm
On Sat, 2022-12-10 at 23:44 -0500, Greg Wooledge wrote:
> On Sat, Dec 10, 2022 at 11:16:12PM -0500, Jim Popovitch wrote:
> > On Sat, 2022-12-10 at 22:10 -0500, Greg Wooledge wrote:
> > > On Sat, Dec 10, 2022 at 10:07:48PM -0500, Jim Popovitch wrote:
>
> > > >
On Sat, Dec 10, 2022 at 11:16:12PM -0500, Jim Popovitch wrote:
> On Sat, 2022-12-10 at 22:10 -0500, Greg Wooledge wrote:
> > On Sat, Dec 10, 2022 at 10:07:48PM -0500, Jim Popovitch wrote:
> > > > > Why does this produce a CR/LF
> > There is still no CR. At all.
On Sat, 2022-12-10 at 22:10 -0500, Greg Wooledge wrote:
> On Sat, Dec 10, 2022 at 10:07:48PM -0500, Jim Popovitch wrote:
> > On Sat, 2022-12-10 at 20:35 -0600, David Wright wrote:
> > > On Sat 10 Dec 2022 at 21:01:29 (-0500), Jim Popovitch wrote:
> > > >
On Sat, 10 Dec 2022 21:01:29 -0500
Jim Popovitch wrote:
> Why does this produce a CR/LF
>
> ~$ TEST=$(ssh -o LogLevel=QUIET -t user@server "echo -n ''"); echo
> ${TEST}
>
> whilst this same command does not:
>
> ~$ ssh -o LogLevel=QUIET -t user@
On Sat, Dec 10, 2022 at 10:07:48PM -0500, Jim Popovitch wrote:
> On Sat, 2022-12-10 at 20:35 -0600, David Wright wrote:
> > On Sat 10 Dec 2022 at 21:01:29 (-0500), Jim Popovitch wrote:
> > > Why does this produce a CR/LF
> > >
> > > ~$ TEST=$(ssh -o Lo
On Sat, 2022-12-10 at 20:35 -0600, David Wright wrote:
> On Sat 10 Dec 2022 at 21:01:29 (-0500), Jim Popovitch wrote:
> > Why does this produce a CR/LF
> >
> > ~$ TEST=$(ssh -o LogLevel=QUIET -t user@server "echo -n ''"); echo ${TEST}
>
> Try ech
On Sat, Dec 10, 2022 at 08:35:59PM -0600, David Wright wrote:
> On Sat 10 Dec 2022 at 21:01:29 (-0500), Jim Popovitch wrote:
> > Why does this produce a CR/LF
> >
> > ~$ TEST=$(ssh -o LogLevel=QUIET -t user@server "echo -n ''"); echo ${TEST}
>
> T
On Sat, Dec 10, 2022 at 09:01:29PM -0500, Jim Popovitch wrote:
> Why does this produce a CR/LF
>
> ~$ TEST=$(ssh -o LogLevel=QUIET -t user@server "echo -n ''"); echo ${TEST}
It does not produce a carriage return, unless you're on Windows.
The second echo
On Sat 10 Dec 2022 at 21:01:29 (-0500), Jim Popovitch wrote:
> Why does this produce a CR/LF
>
> ~$ TEST=$(ssh -o LogLevel=QUIET -t user@server "echo -n ''"); echo ${TEST}
Try echo -n ${TEST} at the end.
> whilst this same command does not:
>
> ~$ ssh
Why does this produce a CR/LF
~$ TEST=$(ssh -o LogLevel=QUIET -t user@server "echo -n ''"); echo ${TEST}
whilst this same command does not:
~$ ssh -o LogLevel=QUIET -t user@server "echo -n ''"
tia,
-Jim P.
On Mon 21 Sep 2020 at 12:16:53 (+1000), David wrote:
> On Mon, 14 Sep 2020 at 21:56, Greg Wooledge wrote:
>
> > There are many ways to work around it. My preferred way is to clear
> > the screen with Ctrl-L (ESC Ctrl-L for me, because I use bash in vi
> > mode). That will redraw the shell promp
On Mon, 14 Sep 2020 at 21:56, Greg Wooledge wrote:
> On Sun, Sep 13, 2020 at 09:14:54PM -0500, David Wright wrote:
> > On Sat 12 Sep 2020 at 21:45:34 (+1000), David wrote:
> > > And regarding "just hit the enter key ... and all is fine", this
> > > behaviour does not just occur at a login prompt.
On Sun, Sep 13, 2020 at 09:14:54PM -0500, David Wright wrote:
> On Sat 12 Sep 2020 at 21:45:34 (+1000), David wrote:
> > And regarding "just hit the enter key ... and all is fine", this
> > behaviour does not just occur at a login prompt. If you login quickly
> > as root to a minimal install as I o
On Sat 12 Sep 2020 at 21:45:34 (+1000), David wrote:
> On Sat, 12 Sep 2020 at 05:18, Felix Miata wrote:
> > Greg Wooledge composed on 2020-09-11 11:42 (UTC-0400):
> > > I only mention it because once in a while, someone sees something like
> > > it and freaks out, thinking the computer is locked u
On Sat, 12 Sep 2020 at 05:18, Felix Miata wrote:
> Greg Wooledge composed on 2020-09-11 11:42 (UTC-0400):
> > On Fri, Sep 11, 2020 at 10:35:46 -0500, David Wright wrote:
>
> >> That's the first mention of this phenomenon I recall seeing since I posted
> >> https://lists.debian.org/debian-user/2018
On Fri 11 Sep 2020 at 15:18:10 (-0400), Felix Miata wrote:
> Greg Wooledge composed on 2020-09-11 11:42 (UTC-0400):
> > On Fri, Sep 11, 2020 at 10:35:46 -0500, David Wright wrote:
>
> >> That's the first mention of this phenomenon I recall seeing since I posted
> >> https://lists.debian.org/debian
Greg Wooledge composed on 2020-09-11 11:42 (UTC-0400):
> On Fri, Sep 11, 2020 at 10:35:46 -0500, David Wright wrote:
>> That's the first mention of this phenomenon I recall seeing since I posted
>> https://lists.debian.org/debian-user/2018/03/msg01030.html
>> (which dealt mainly with a more serio
[EMAIL PROTECTED] writes:
> #include
> #include
Are you posting homework assignments here, or are you unaware of the
much simpler ways to do this?
--
Alan Shutko <[EMAIL PROTECTED]> - In a variety of flavors!
If this fortune didn't exist, somebody would have invented it.
* [EMAIL PROTECTED] ([EMAIL PROTECTED]) [011109 18:13]:
why switch? how about:
> #include
>
> int main()
> {
> char ch;
>
> while(!cin.eof() ){
> cin.get(ch);
if(ch != '\r') {
cout << ch;
}
> }
>
> return 0;
> }
(see also /usr/bin/tr for
#include
#include
using namespace std;
void process_file(int argc, char **argv);
void process_stdin();
void check_char(char &ch);
int main(int argc, char **argv)
{
if(argc > 1)
process_file(argc, argv);
else
process_stdin();
return 0;
}
void process_file(int argc,
#include
int main()
{
char ch;
while(!cin.eof() ){
cin.get(ch);
switch(ch){
case '\r':
break;
default:
cout << ch;
}
}
return 0;
}
I'm using modemu/minicom so I can transfer files
with zmodem to a couple dialup accounts. But it's
unusable with one account because text scrolls
off the right -- all line feeds and no carriage
returns incoming?
I've played with TERM settings on my machine and
minicom's translation table (lfs ->
44 matches
Mail list logo
