Why are here no line feeds/CRs ?
Jochen Berninger
No CR/line feeds split the output into multiple lines as usual.
Whats wrong?
echo `date; ls -l; date` >>filelist.txt
Jochen
Mickey
You are echoing words processed by the shell, not outputting
commands. Do instead:
(date; ls -l; date) >> filelist.txt
--
Mickey
{((>:o}~ <<<<Oh look!!! An idolatrous image of the prophet!!! Surely
we must now avenge this blasphemy by burning down the world!!!
Ed Morton
> When I issue the following command then the output is concatenated as ONE (!) very long line.
> No CR/line feeds split the output into multiple lines as usual.
>
> Whats wrong?
Nothing.
> echo `date; ls -l; date` >>filelist.txt
You're calling echo with multiple arguments (i.e. all the text output by the
other commands) and it's printing them one at a time with a space between each
just as it's supposed to. If that's not what you want, do either of these:
{ date; ls -l; date; } >>filelist.txt
echo "`date; ls -l; date`" >>filelist.txt
the first one being preferable.
Ed.
Grant Edwards
Nothing is wrong.
Quoting from the Bash manual:
3.5.4 Command Substitution
--------------------------
Command substitution allows the output of a command to
replace the command itself. Command substitution occurs when
a command is enclosed as follows:
$(COMMAND)
or
`COMMAND`
Bash performs the expansion by executing COMMAND and
replacing the command substitution with the standard output
of the command, with any trailing newlines deleted. Embedded
newlines are not deleted, but they may be removed during word
splitting. The command substitution $(cat FILE)' can be
replaced by the equivalent but faster $(< FILE)'.
When the old-style backquote form of substitution is used,
backslash retains its literal meaning except when followed by
$', `', or \'. The first backquote not preceded by a
backslash terminates the command substitution. When using
the $(COMMAND)' form, all characters between the parentheses
make up the command; none are treated specially.
Command substitutions may be nested. To nest when using the
backquoted form, escape the inner backquotes with
backslashes.
If the substitution appears within double quotes, word
splitting and filename expansion are not performed on the
results.
Take note where it says " Embedded newlines are not deleted,
but they may be removed during word splitting". When the
command line is parsed into arguments to be passed to echo, the
newlines are removed along with other whitespace between words.
You can get the results you seem to want by doing this:
(date; ls -l; dat) >>filelist.txt
or this:
echo "`date; ls -l; date`" >>filelist.txt
--
Grant Edwards grante Yow! If I am elected no one
at will ever have to do their
visi.com laundry again!
John Gordon
> Whats wrong?
Depending on what shell you're using, wrapping the argments to echo
in double-quotes might work, like so:
echo "`date; ls -l; date`" >>filelist.txt
But really, using "echo" is just complicating the issue. Is there any
special reason you're not just executing the commands directly, like so?
date >> filelist.txt
ls -l >> filelist.txt
date >> filelist.txt
And I'm curious -- why are you posting under different names? That
usually indicates someone who's up to no good.
--
John Gordon A is for Amy, who fell down the stairs
gor...@panix.com B is for Basil, assaulted by bears
-- Edward Gorey, "The Gashlycrumb Tinies"
Janis
> When I issue the following command then the output is concatenated as ONE (!) very long line.
> No CR/line feeds split the output into multiple lines as usual.
>
> Whats wrong?
Nothing is wrong; the command substitution `...` resp. $(...) works as
designed.
>
> echo `date; ls -l; date` >>filelist.txt
{ date; ls -l; date; } >>filelist.txt
Janis
>
> Jochen
Wenhua Zhao
Hi,
It seems that echo eats all the LF. The following should work:
(data; ls -l; data) >> filelist.txt
>
> Jochen
Bill Marcum
You can either enclose the backquotes in double quotes, or eliminate them:
echo "`date; ls -l; date`" >>filelist.txt
{ date; ls -l; date; } >>filelist.txt
Unruh
>Whats wrong?
because ls -l splits up the line according the (non-esitant ) terminal.
Try
(date;ls -l; date)>>filelist.txt
>Jochen
mop2
wrote:
You need quotes to preserve control characters, LF for example:
echo "`date; ls -l; date`"
Or you can do:
{ date; ls -l; date;}
Maxwell Lol
Grant Edwards
>>When I issue the following command then the output is
>>concatenated as ONE (!) very long line. No CR/line feeds split
>>the output into multiple lines as usual.
>
>>Whats wrong?
>
>>echo `date; ls -l; date` >>filelist.txt
>
> because ls -l splits up the line according the (non-esitant ) terminal.
No, that's not why.
The "ls" command is outputting newlines. The newlines are
discarded by the shell as it splits the output of the three
commands into words before passing them to echo in an argv
vector.
--
Grant Edwards grante Yow! Is this my STOP??
at
visi.com
Barry Margolin
buz...@hotmail.com (Jochen Berninger) wrote:
When you don't quote the backtick expression, word splitting is
performed on the result, which causes all whitespace sequences to be
translated to a space. Try:
echo "`date; ls -l; date`" >>filelist.txt
But why use echo at all? Why not:
{ date; ls -l; date; } >>filelist.txt
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
Joachim Schmitz
(date; ls -l; date) >>filelist.txt
>
> Jochen
Bye, Jojo
Adrian Davis
Try...
echo "`date; ls -l; date`" >> filelist.txt
Best Regards,
=Adrian=
Maxwell Lol
After reading 10+ idential replies (including my own, as I don't
subscribe to this newsgroup), is seems to me that setting the
follow-up to a single newsgroup will cause redundant answers, as we
don't see what others post before we reply.
Sigh... The manual pages provides all the answers you need - and faster too.
Grant Edwards
> After reading 10+ idential replies (including my own, as I
> don't subscribe to this newsgroup), is seems to me that
> setting the follow-up to a single newsgroup will cause
> redundant answers, as we don't see what others post before we
> reply.
That's mainly just due to the latency inherent in Usenet.
> Sigh... The manual pages provides all the answers you need -
> and faster too.
Usually -- if you know which man page to look at. :)
--
Grant Edwards grante Yow! I'm totally DESPONDENT
at over the LIBYAN situation
visi.com and the price of CHICKEN
...
Andrew
> On 2008-05-21, Maxwell Lol <nos...@com.invalid> wrote:
>
> > After reading 10+ idential replies (including my own, as I
> > don't subscribe to this newsgroup), is seems to me that
> > setting the follow-up to a single newsgroup will cause
> > redundant answers, as we don't see what others post before we
> > reply.
>
> That's mainly just due to the latency inherent in Usenet.
No, what he is referring to here is the followup-to: header. I read
this message in comp.unix.shell and no responses are in that group so
it is easy to assume that there have been none. I only noticed the
header when my newsreader asked me if I wanted to post my carefully
composed response to comp.os.linux.misc as the poster requested did it
occur to me that there may have already been some responses. Mosey
over to Google groups to check the thread there and I see all the
previous posts that didn't go to comp.unix.shell and
comp.unix.questions.
Setting Followup-to: in this manner is a good way of wasting
everyone's time because the replies _are_ invisible to many readers
who will quite naturally assume that the post has received no
responses and so compose their own. And as has been noted, the group
that is the target of the header is swamped with several identical
posts. It is for this very reason that I ignore the header and
respond to all groups. You will notice I have added back
comp.unix.shell and comp.unix.questions to this post so that hopefully
no-one else needs to waste their time replying.
For a simple query like this there isn't really any need to cross post
among multiple groups anyway.
--
Andrew Smallshaw
and...@sdf.lonestar.org
#! /shell/nerd
Try -