Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

input.txt

 EN1
 EN2
 EN3
 EN4
 EN5

output

EN1,EN2,EN3,EN4,EN5

I have tried awk.But it is not printing with comma

awk 'BEGIN { OFS = ","} { printf $1}' input.txt

I have GNU Awk 4.0.0 version

share|improve this question
    
Strange, ORS should separate the line (records) with commas, it's hard to believe v 4.0 of gawk would change that .. but it looks that way based on your experience. –  Levon Aug 3 '12 at 22:05
    
So you were not looking for an awk solution .. –  Levon Aug 7 '12 at 15:18

5 Answers 5

up vote 4 down vote accepted
awk 'BEGIN{ORS=","}1' input.txt

yields this:

EN1,EN2,EN3,EN4,EN5,

so is printing with a comma (so I'm not sure I understand your comment in your post about this not happening) though I suspect the trailing comma is a problem.

Tested with GNU Awk 3.1.7

share|improve this answer
    
It is printing without comma eg. EN1EN2EN3EN4EN5 –  jack Aug 3 '12 at 21:47
    
what version of awk are you using? This is odd, since I pasted this in from the console. –  Levon Aug 3 '12 at 21:49
2  
The question has used OFS, this answer uses ORS .. that explains the difference in behaviour... printf doesn't produce an ORS –  Peter.O Aug 3 '12 at 23:58

You can use tr in such situation.

tr '\n' ',' <input.txt

This replaces the final newline by a comma as well. To avoid this, on Linux, if you know that the input file does end with a newline:

<input.txt head -c -1 | tr '\n' ,

Add ; echo if you want the output to be terminated by a newline.

Alternatively, you can get the shell to remove a trailing comma if there is one.

columns=$(<input.txt tr '\n' ',')
echo "${columns%,}"
share|improve this answer
    
Oddly enough, this gives me an "extra operand" error message, but tr '\n' ',' < input.txt works fine, but also with a trailing comma. –  Levon Aug 3 '12 at 21:59
    
@Levon See my edit –  Gilles Aug 3 '12 at 23:02
    
@Gilles Neat .. works nice (don't come often across a command that starts with <) –  Levon Aug 7 '12 at 15:09
perl -pe '(eof)?s/\s+$//:s/\s+$/,/' input.txt  

output: no trailing \n

EN1,EN2,EN3,EN4,EN5
share|improve this answer

There's also xargs and sed:

$ xargs <input.txt | sed -e 's/ /,/g'
EN1,EN2,EN3,EN4,EN5

An advantage here is that there is no trailing comma to get rid of.

xargs to combine the input lines, sed to replace all spaces with commas. I use this routinely to construct regular expressions (replace spaces with |) and quick sums to pipe into bc (replace spaces with +).

(FYI xargs defaults to echo as the command if none is provided)

NOTE: This only works if the input file is as described (one field per line, no spaces). If there are more fields and/or spaces in the input you can use awk or sed to pre-process the input. For example, with input like this:

EN1 foo bar
EN2 bar foo
EN3 baz quux
EN4 abc def
EN5 hij klm

Here awk is used to extract only the first field:

$ awk '{print $1}' input.txt | xargs | sed -e 's/ /,/g'
EN1,EN2,EN3,EN4,EN5

In this second (sed) example, spaces in the original input are replaced with some other string (chosen as unlikely to be in the original input), then fed into xargs. sed then replaces the spaces added by xargs, and then restores the strings from the input:

$ sed -e 's/ /--space--/g' input.txt | xargs | sed -e 's/ /,/g' -e 's/--space--/ /g'
EN1 foo bar,EN2 bar foo,EN3 baz quux,EN4 abc def,EN5 hij klm

Now for some gratuitous op-ed commentary:

One of the most useful pieces of knowledge about unix text processing tools is that you can and should should think of data as being almost infinitely malleable - you can transform it into whatever form you need either to provide input to another process or to produce the output you want or both.

This is part of the reason why unix people tend to hate proprietary data formats - it's not just a philosophical disapproval or a wish to avoid vendor lock-in, it's also the very pragmatic fact that they make it difficult for us to manipulate and use our data in ways that weren't foreseen by the software's developers.

share|improve this answer
    
It won't be a problem in most cases, and it is certainly very useful for what you have mentioned, but it does output a trailing \n, and if xargs needs to invoke echo multiple times due to command-line args limits, sed will introduce more spurious \ns; one for each extra call ...(+1 BTW) –  Peter.O Aug 4 '12 at 19:58
    
PS.. I just noticed that xargs echo -n avoids the \n issue... but sed can hit a memory limit (it did in my rather large scale tests), so it should be fine if you aren't dealing with gigabyte+ long command lines ;) –  Peter.O Aug 4 '12 at 20:20
    
yeah, well, xargs will split them long before command lines get to a gigabyte :). I've occasionally run into problems when generating huge command lines from find /really/stupidly/long/path/.../ | xargs but that's more an issue with the command i'm feeding it into than with xargs (e.g. 'du -sh' may generate multiple total lines which then need to be added), and is solvable with a suitable wrapper script or post-processing. –  cas Aug 5 '12 at 10:06

I know, old topic, but I could not resist - here's yet another short and simple way to do this:

$ paste -sd, input.txt
EN1,EN2,EN3,EN4,EN5
$

Works on Linux and Solaris, maybe even on other platforms.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.