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

Jochen

On 2008-05-20, Jochen Berninger <buz...@hotmail.com> wrote:

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

On 5/20/2008 3:49 PM, Jochen Berninger wrote:

Nothing.

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.

On 2008-05-20, Jochen Berninger <buz...@hotmail.com> wrote:

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!

In <4833395f$0$6503$9b4e6...@newsspool4.arcor-online.net> buz...@hotmail.com (Jochen Berninger) writes:

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"

On 20 Mai, 23:49, buz...@hotmail.com (Jochen Berninger) wrote:

Nothing is wrong; the command substitution `...` resp. $(...) works as
designed.

  { date; ls -l; date; } >>filelist.txt

Janis

Hi,

It seems that echo eats all the LF.  The following should work:

(data; ls -l; data) >> filelist.txt

On 2008-05-20, Jochen Berninger <buz...@hotmail.com> wrote:

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

because ls -l splits up the line according the (non-esitant ) terminal.

Try
(date;ls -l; date)>>filelist.txt

On Tue, 20 May 2008 17:49:35 -0300, Jochen Berninger <buz...@hotmail.com>  
wrote:

You need quotes to preserve control characters, LF for example:
echo "`date; ls -l; date`"

Or you can do:
{ date; ls -l; date;}

That's what `.....` does. You want

        (date; ls -l; date) >>filelist.txt

On 2008-05-20, Unruh <unruh-s...@physics.ubc.ca> wrote:

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            

In article <4833395f$0$6503$9b4e6...@newsspool4.arcor-online.net>,
 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 ***

use
(date; ls -l; date) >>filelist.txt

Bye, Jojo

Try...

echo "`date; ls -l; date`" >> filelist.txt

Best Regards,
   =Adrian=

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.

On 2008-05-21, Maxwell Lol <nos...@com.invalid> wrote:

That's mainly just due to the latency inherent in Usenet.

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

On 21 May, 15:06, Grant Edwards <gra...@visi.com> wrote:

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
andr...@sdf.lonestar.org

On May 20, 3:49 pm, buz...@hotmail.com (Jochen Berninger) wrote:

Try -

(date; ls -l; date) >> filelist.txt