Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #224795 > unrolled thread

delimiters with more than one character? ...

Back to article view | Back to linux.debian.user

Contents

  delimiters with more than one character? ... Albretch Mueller <lbrtchx@gmail.com> - 2020-07-14 15:00 +0200
    Re: delimiters with more than one character? ... Alex Mestiashvili <amestia@rsh2.donotuse.de> - 2020-07-14 15:00 +0200
      Re: delimiters with more than one character? ... Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-14 15:10 +0200
        Re: delimiters with more than one character? ... Nicolas George <george@nsup.org> - 2020-07-14 15:10 +0200
        Re: delimiters with more than one character? ... Alex Mestiashvili <amestia@rsh2.donotuse.de> - 2020-07-14 15:20 +0200
    Re: delimiters with more than one character? ... Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-14 15:10 +0200
    Re: delimiters with more than one character? ... Nicolas George <george@nsup.org> - 2020-07-14 15:20 +0200
    Re: delimiters with more than one character? ... Nicolas George <george@nsup.org> - 2020-07-14 17:30 +0200
      Re: delimiters with more than one character? ... Albretch Mueller <lbrtchx@gmail.com> - 2020-07-15 12:30 +0200
        Re: delimiters with more than one character? ... Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-15 14:00 +0200
        Re: delimiters with more than one character? ... David Wright <deblis@lionunicorn.co.uk> - 2020-07-15 14:30 +0200
        Re: delimiters with more than one character? ... Bob Weber <bobrweber@gmail.com> - 2020-07-15 14:40 +0200
          Re: delimiters with more than one character? ... Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-15 14:50 +0200
            Re: delimiters with more than one character? ... Bob Weber <bobrweber@gmail.com> - 2020-07-15 16:20 +0200
              Re: delimiters with more than one character? ... Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-15 16:30 +0200
              Re: delimiters with more than one character? ... The Wanderer <wanderer@fastmail.fm> - 2020-07-15 16:30 +0200
              Re: delimiters with more than one character? ... Nicolas George <george@nsup.org> - 2020-07-15 17:50 +0200
          Re: delimiters with more than one character? ... Nicolas George <george@nsup.org> - 2020-07-15 15:10 +0200
    Re: delimiters with more than one character? ... Bob Weber <bobrweber@gmail.com> - 2020-07-14 17:30 +0200
    Re: delimiters with more than one character? ... Alessandro Baggi <alessandro.baggi@gmail.com> - 2020-07-15 17:30 +0200
    Re: delimiters with more than one character? ... Eric S Fraga <e.fraga@ucl.ac.uk> - 2020-07-16 12:10 +0200
      Re: delimiters with more than one character? ... "Thomas Schmitt" <scdbackup@gmx.net> - 2020-07-16 13:40 +0200
        Re: delimiters with more than one character? ... Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-16 14:00 +0200
          Re: delimiters with more than one character? ... Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-16 16:00 +0200
            Re: delimiters with more than one character? ... Zenaan Harkness <zenaan@freedbms.net> - 2020-07-17 04:50 +0200
              Re: delimiters with more than one character? ... Nicolas George <george@nsup.org> - 2020-07-17 10:50 +0200
                Re: delimiters with more than one character? ... rhkramer@gmail.com - 2020-07-17 13:20 +0200
                  tmpfs is not a ramdisk (was: delimiters with more than one  character? ...) Nicolas George <george@nsup.org> - 2020-07-17 13:30 +0200
                    Re: tmpfs is not a ramdisk (was: delimiters with more than one  character? ...) David Wright <deblis@lionunicorn.co.uk> - 2020-07-17 18:20 +0200
                      Re: tmpfs is not a ramdisk (was: delimiters with more than one character? ...) rhkramer@gmail.com - 2020-07-17 20:30 +0200
                        Re: tmpfs is not a ramdisk (was: delimiters with more than one  character? ...) Zenaan Harkness <zenaan@freedbms.net> - 2020-07-18 07:20 +0200
                        Re: tmpfs is not a ramdisk (was: delimiters with more than one  character? ...) <tomas@tuxteam.de> - 2020-07-18 10:40 +0200
                  Re: delimiters with more than one character? ... Greg Wooledge <wooledg@eeg.ccf.org> - 2020-07-17 13:40 +0200
          Re: delimiters with more than one character? ... "Thomas Schmitt" <scdbackup@gmx.net> - 2020-07-16 16:00 +0200
          Re: delimiters with more than one character? ... Zenaan Harkness <zenaan@freedbms.net> - 2020-07-17 04:50 +0200
        Re: delimiters with more than one character? ... Eric S Fraga <e.fraga@ucl.ac.uk> - 2020-07-16 15:00 +0200
    Re: delimiters with more than one character? ... John Crawley <john@bunsenlabs.org> - 2020-08-05 08:30 +0200
      Re: delimiters with more than one character? ... Greg Wooledge <wooledg@eeg.ccf.org> - 2020-08-05 15:10 +0200
        Re: delimiters with more than one character? ... John Crawley <john@bunsenlabs.org> - 2020-08-06 05:00 +0200
          Re: delimiters with more than one character? ... Greg Wooledge <wooledg@eeg.ccf.org> - 2020-08-06 13:40 +0200
            Re: delimiters with more than one character? ... John Crawley <john@bunsenlabs.org> - 2020-08-07 03:10 +0200

Page 1 of 3  [1] 2 3  Next page →

#224795 — delimiters with more than one character? ...

 I have a string delimited by two characters: "\|"

 _S=" 34 + 45 \| abc \| 1 2 3 \| c\|123abc "

 which then I need to turn into a array looking like:

  _S_AR=(
" 34 + 45 "
" abc "
" 1 2 3 "
" c"
"123abc "
)

  I can't make awk or tr work in the way I need and all examples I
have found use only one character.

  Is it possible to do such things in bash?

  lbrtchx

[toc] | [next] | [standalone]

#224796

On 7/14/20 2:52 PM, Albretch Mueller wrote:
>   I have a string delimited by two characters: "\|"
> 
>   _S=" 34 + 45 \| abc \| 1 2 3 \| c\|123abc "
> 
>   which then I need to turn into a array looking like:
> 
>    _S_AR=(
> " 34 + 45"
> " abc"
> " 1 2 3"
> " c"
> "123abc"
> )
> 
>    I can't make awk or tr work in the way I need and all examples I
> have found use only one character.
> 
>    Is it possible to do such things in bash?
> 
>    lbrtchx
> 

Please share the solution you tried.

Since you anyway use tools like awk or tr, here is the perl code:

echo " 34 + 45 \| abc \| 1 2 3 \| c\|123abc " | perl -F'\\\|' -lanE 'say 
"\"".$_."\"" for @F'

Best,
Alex

[toc] | [prev] | [next] | [standalone]

#224797

On Tue, Jul 14, 2020 at 03:04:38PM +0200, Alex Mestiashvili wrote:
> Since you anyway use tools like awk or tr, here is the perl code:
> 
> echo " 34 + 45 \| abc \| 1 2 3 \| c\|123abc " | perl -F'\\\|' -lanE 'say
> "\"".$_."\"" for @F'

If you're going to call on perl to help split the string into an
array, you might as well throw bash away and write the entire program
in perl instead.

[toc] | [prev] | [next] | [standalone]

#224798

[Multipart message — attachments visible in raw view] — view raw

Greg Wooledge (12020-07-14):
> > echo " 34 + 45 \| abc \| 1 2 3 \| c\|123abc " | perl -F'\\\|' -lanE 'say
> > "\"".$_."\"" for @F'
> 
> If you're going to call on perl to help split the string into an
> array, you might as well throw bash away and write the entire program
> in perl instead.

I concur. And I would advise against using the features of perl that
makes it automatically behave somewhat like awk or others, with implicit
parameters and the like. Better write what you mean explicitly and
readably.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#224801

On 7/14/20 3:05 PM, Greg Wooledge wrote:
> On Tue, Jul 14, 2020 at 03:04:38PM +0200, Alex Mestiashvili wrote:
>> Since you anyway use tools like awk or tr, here is the perl code:
>>
>> echo " 34 + 45 \| abc \| 1 2 3 \| c\|123abc " | perl -F'\\\|' -lanE 'say
>> "\"".$_."\"" for @F'
> 
> If you're going to call on perl to help split the string into an
> array, you might as well throw bash away and write the entire program
> in perl instead.
> 

That's what I usually do. IMHO bash scripting is awful in many ways, 
insecure and plain dangerous :) Perl in this regard is way better.

However I see no point here, if you use awk or other tools, what's wrong 
with perl oneliners?

[toc] | [prev] | [next] | [standalone]

#224799

On Tue, Jul 14, 2020 at 02:52:08PM +0200, Albretch Mueller wrote:
>  I have a string delimited by two characters: "\|"
> 
>  _S=" 34 + 45 \| abc \| 1 2 3 \| c\|123abc "
> 
>  which then I need to turn into a array looking like:
> 
>   _S_AR=(
> " 34 + 45 "
> " abc "
> " 1 2 3 "
> " c"
> "123abc "
> )
> 
>   I can't make awk or tr work in the way I need and all examples I
> have found use only one character.
> 
>   Is it possible to do such things in bash?

Not using shell builtin tools, no.  (Well, you could always iterate
over the string character by character

You can convince awk to do it, and produce a modified data stream
that bash can parse.

unicorn:~$ printf '%s\n' "$_S" | awk -F '\\\\[|]' '{for(i=1; i<=NF; i++) {printf("%s\0",$i)}}' | hd
00000000  20 33 34 20 2b 20 34 35  20 00 20 61 62 63 20 00  | 34 + 45 . abc .|
00000010  20 31 20 32 20 33 20 00  20 63 00 31 32 33 61 62  | 1 2 3 . c.123ab|
00000020  63 20 00                                          |c .|
00000023

So, there's our modified stream, with NUL delimiters.  Bash 4.4 and
above can read that directly into an array:

unicorn:~$ mapfile -t -d '' array < <(printf '%s\n' "$_S" | awk -F '\\\\[|]' '{for(i=1; i<=NF; i++) {printf("%s\0",$i)}}')
unicorn:~$ declare -p array
declare -a array=([0]=" 34 + 45 " [1]=" abc " [2]=" 1 2 3 " [3]=" c" [4]="123abc ")

With bash versions older than 4.4, mapfile does not have the -d ''
option, so you'd need a loop to populate an array from the NUL-delimited
stream.

There may be other ways, but this is the first one that came to mind.

[toc] | [prev] | [next] | [standalone]

#224800

[Multipart message — attachments visible in raw view] — view raw

Albretch Mueller (12020-07-14):
>  I have a string delimited by two characters: "\|"
> 
>  _S=" 34 + 45 \| abc \| 1 2 3 \| c\|123abc "
> 
>  which then I need to turn into a array looking like:
> 
>   _S_AR=(
> " 34 + 45 "
> " abc "
> " 1 2 3 "
> " c"
> "123abc "
> )
> 
>   I can't make awk or tr work in the way I need and all examples I
> have found use only one character.
> 
>   Is it possible to do such things in bash?

In bash I do not know, but zsh can do it easily:

$ a="abcxydefxyghi"; echo ${(s:xy:)a}
abc def ghi

I leave as an exercise the task of properly escaping backslash and pipe
if necessary.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#224803

[Multipart message — attachments visible in raw view] — view raw

Bob Weber (12020-07-14):
> echo " 34 + 45 \| abc \| 1 2 3 \| c\|123abc " | tr -d '\\' | awk 'BEGIN {
> FS="|" } { printf "
> _S_AR=(\n\"%s\"\n\"%s\"\n\"%s\"\n\"%s\"\n\"%s\"\n)\n",$1,$2,$3,$4,$5}'

Have you considered that pipes without backslashes are not supposed to
be separators?

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#224832

On 7/14/20, Nicolas George <george@nsup.org> wrote:
> Bob Weber (12020-07-14):
>> echo " 34 + 45 \| abc \| 1 2 3 \| c\|123abc " | tr -d '\\' | awk 'BEGIN {
>> FS="|" } { printf "
>> _S_AR=(\n\"%s\"\n\"%s\"\n\"%s\"\n\"%s\"\n\"%s\"\n)\n",$1,$2,$3,$4,$5}'
>
> Have you considered that pipes without backslashes are not supposed to
> be separators?

 the thing is that that was the one liner passed to a find command
which then I need to use as an array

 lbrtchx

[toc] | [prev] | [next] | [standalone]

#224835

On Wed, Jul 15, 2020 at 06:29:38AM -0400, Albretch Mueller wrote:
> On 7/14/20, Nicolas George <george@nsup.org> wrote:
> > Bob Weber (12020-07-14):
> >> echo " 34 + 45 \| abc \| 1 2 3 \| c\|123abc " | tr -d '\\' | awk 'BEGIN {
> >> FS="|" } { printf "
> >> _S_AR=(\n\"%s\"\n\"%s\"\n\"%s\"\n\"%s\"\n\"%s\"\n)\n",$1,$2,$3,$4,$5}'
> >
> > Have you considered that pipes without backslashes are not supposed to
> > be separators?
> 
>  the thing is that that was the one liner passed to a find command
> which then I need to use as an array

I'm pretty sure you don't mean "find" here.

GNU grep, perhaps?  GNU grep is infamous for its many stupid extensions,
one of which is the use of \| in BRE mode to simulate | from ERE mode.

[toc] | [prev] | [next] | [standalone]

#224836

On Wed 15 Jul 2020 at 06:29:38 (-0400), Albretch Mueller wrote:
> On 7/14/20, Nicolas George <george@nsup.org> wrote:
> > Bob Weber (12020-07-14):
> >> echo " 34 + 45 \| abc \| 1 2 3 \| c\|123abc " | tr -d '\\' | awk 'BEGIN {
> >> FS="|" } { printf "
> >> _S_AR=(\n\"%s\"\n\"%s\"\n\"%s\"\n\"%s\"\n\"%s\"\n)\n",$1,$2,$3,$4,$5}'
> >
> > Have you considered that pipes without backslashes are not supposed to
> > be separators?
> 
>  the thing is that that was the one liner passed to a find command
> which then I need to use as an array

I'm at a loss. Why make up a string with difficult-to-handle
delimiters, and then try to turn it into an array?

Why not put those strings into an array, and then use that array to
build your find command?

And what is it about one-liners? Are you in some sort of shelling competition?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#224840

[Multipart message — attachments visible in raw view] — view raw

On 7/15/20 6:29 AM, Albretch Mueller wrote:
> the thing is that that was the one liner passed to a find command
> which then I need to use as an array
>
>   lbrtchx

My only purpose was to show how tr could be used to handle multiple characters 
as a delimiter either as tr -s '\\\|' '\|' or

tr -d '\\' when used with awk.  Plus the use of awk's printf command to produce the output you wanted.  Please explain what you are trying to do so we can be more helpful.

-- 


*...Bob*

[toc] | [prev] | [next] | [standalone]

#224842

On Wed, Jul 15, 2020 at 08:34:36AM -0400, Bob Weber wrote:
> My only purpose was to show how tr could be used to handle multiple
> characters as a delimiter either as tr -s '\\\|' '\|' or

The problem is, it can't, at least not the way you showed.  The original
example, sadly, did NOT contain instances of the | and \ characters in
isolation, so one might be lulled into a false sense of security, and
write code that (for example) simply deletes all of the \ characters,
and then splits on the | characters.

But that won't work in the general case, where | and \ might appear as
literal data characters.

My own solution, which involved using awk to convert the \| pairs into
NUL bytes, is also technically incorrect.  However, there was an
additional stipulation: the stream was to be converted into a bash
array.  A bash array is a list of C strings, so they cannot contain
NUL bytes.  Therefore you can't possibly have NUL bytes in the original
input stream (at least, not and still produce a bash array), so my
conversion of the multi-character delimiters into NUL bytes will "work".

But it's a freaking ugly problem any way you look at it, and it just
got uglier when it was revealed that the OP might be trying to write
shell code that parses shell code.  Especially if the code in question
is a series of poorly written GNU-tainted grep commands.

[toc] | [prev] | [next] | [standalone]

#224850

[Multipart message — attachments visible in raw view] — view raw

On 7/15/20 8:44 AM, Greg Wooledge wrote:
> On Wed, Jul 15, 2020 at 08:34:36AM -0400, Bob Weber wrote:
>> My only purpose was to show how tr could be used to handle multiple
>> characters as a delimiter either as tr -s '\\\|' '\|' or
> The problem is, it can't, at least not the way you showed.  The original
> example, sadly, did NOT contain instances of the | and \ characters in
> isolation, so one might be lulled into a false sense of security, and
> write code that (for example) simply deletes all of the \ characters,
> and then splits on the | characters.
>
> But that won't work in the general case, where | and \ might appear as
> literal data characters.
>
> My own solution, which involved using awk to convert the \| pairs into
> NUL bytes, is also technically incorrect.  However, there was an
> additional stipulation: the stream was to be converted into a bash
> array.  A bash array is a list of C strings, so they cannot contain
> NUL bytes.  Therefore you can't possibly have NUL bytes in the original
> input stream (at least, not and still produce a bash array), so my
> conversion of the multi-character delimiters into NUL bytes will "work".
>
> But it's a freaking ugly problem any way you look at it, and it just
> got uglier when it was revealed that the OP might be trying to write
> shell code that parses shell code.  Especially if the code in question
> is a series of poorly written GNU-tainted grep commands.
>
Which is why I showed this:

tr -s '\\\|' '\|'

which replaces \| with a single character which is known not to be in the input data and usable as a awk field separator.  It just happens to be a | which is ok with awk and and I have used as a separator in code over 30 years ago.

-- 


*...Bob*

[toc] | [prev] | [next] | [standalone]

#224851

On Wed, Jul 15, 2020 at 10:11:08AM -0400, Bob Weber wrote:
> Which is why I showed this:
> 
> tr -s '\\\|' '\|'
> 
> which replaces \| with a single character which is known not to be in the input data and usable as a awk field separator.  It just happens to be a |

You misunderstood my point.  The | character COULD be in the input data.
So could the \ character.

What does your command do with input that contains standalone | and \
characters?

unicorn:~$ echo '| \ |\ \| |' | tr -s '\\\|' '\|'
| | | | |

The wrong thing.

The tr command is never going to be suited to identifying multi-character
delimiter strings.  It wasn't built for that.  It's simply the wrong
tool for this job.

[toc] | [prev] | [next] | [standalone]

#224852

[Multipart message — attachments visible in raw view] — view raw

On 2020-07-15 at 10:11, Bob Weber wrote:

> On 7/15/20 8:44 AM, Greg Wooledge wrote:
> 
>> On Wed, Jul 15, 2020 at 08:34:36AM -0400, Bob Weber wrote:
>> 
>>> My only purpose was to show how tr could be used to handle
>>> multiple characters as a delimiter either as tr -s '\\\|' '\|'
>>> or
>> 
>> The problem is, it can't, at least not the way you showed.  The
>> original example, sadly, did NOT contain instances of the | and \
>> characters in isolation, so one might be lulled into a false sense
>> of security, and write code that (for example) simply deletes all
>> of the \ characters, and then splits on the | characters.
>> 
>> But that won't work in the general case, where | and \ might appear
>> as literal data characters.
>> 
>> My own solution, which involved using awk to convert the \| pairs
>> into NUL bytes, is also technically incorrect.  However, there was
>> an additional stipulation: the stream was to be converted into a
>> bash array.  A bash array is a list of C strings, so they cannot
>> contain NUL bytes.  Therefore you can't possibly have NUL bytes in
>> the original input stream (at least, not and still produce a bash
>> array), so my conversion of the multi-character delimiters into NUL
>> bytes will "work".
>> 
>> But it's a freaking ugly problem any way you look at it, and it
>> just got uglier when it was revealed that the OP might be trying to
>> write shell code that parses shell code.  Especially if the code in
>> question is a series of poorly written GNU-tainted grep commands.
>> 
> Which is why I showed this:
> 
> tr -s '\\\|' '\|'
> 
> which replaces \| with a single character which is known not to be in
> the input data

How do you know that?

We don't necessarily have the full input data set. We have a sample
input data set, which may or may not be the only one that will ever be
used.

If '|' were guaranteed to never occur in the input data, it would
probably have been selected as the delimiter standalone, rather than
only as part of the '\|' pair.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

[toc] | [prev] | [next] | [standalone]

#224859

[Multipart message — attachments visible in raw view] — view raw

Bob Weber (12020-07-15):
> which replaces \| with a single character which is known not to be in
> the input data

For the third time, and on top of what other people have told you:

THERE ARE NO CHARACTERS KNOWN NOT TO BE IN THE INPUT.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#224845

Bob Weber (12020-07-15):
> My only purpose was to show how tr could be used to handle multiple
> characters as a delimiter either as tr -s '\\\|' '\|' or

A simple combinatorics argument should convince you that the trick of
turning a 2-chars delimiter into a 1-char delimiter cannot work in all
cases.

Regards,

-- 
  Nicolas George

[toc] | [prev] | [next] | [standalone]

#224804

[Multipart message — attachments visible in raw view] — view raw

On 7/14/20 8:52 AM, Albretch Mueller wrote:
>   I have a string delimited by two characters: "\|"
>
>   _S=" 34 + 45 \| abc \| 1 2 3 \| c\|123abc "
>
>   which then I need to turn into a array looking like:
>
>    _S_AR=(
> " 34 + 45"
> " abc"
> " 1 2 3"
> " c"
> "123abc"
> )
>
Try:

echo " 34 + 45 \| abc \| 1 2 3 \| c\|123abc " | tr -d '\\' | awk 'BEGIN { FS="|" 
} { printf " _S_AR=(\n\"%s\"\n\"%s\"\n\"%s\"\n\"%s\"\n\"%s\"\n)\n",$1,$2,$3,$4,$5}'

All one line.

First tr deletes the backslash leaving the pipe for a field separator in awk.  
You could also use tr -s '\\\|' '\|' to guarantee that you only work on the \| 
combination in case there are other backslashes not followed by a pipe.


-- 


*...Bob*

[toc] | [prev] | [next] | [standalone]

#224858

Il 14/07/20 14:52, Albretch Mueller ha scritto:
>   I have a string delimited by two characters: "\|"
>
>   _S=" 34 + 45 \| abc \| 1 2 3 \| c\|123abc "
>
>   which then I need to turn into a array looking like:
>
>    _S_AR=(
> " 34 + 45"
> " abc"
> " 1 2 3"
> " c"
> "123abc"
> )
>
>    I can't make awk or tr work in the way I need and all examples I
> have found use only one character.
>
>    Is it possible to do such things in bash?
>
>    lbrtchx
>
Hi Albretch,

I would ask why use this type of separators for fields and try to manage 
them in bash when one is used for character escaping and the other is 
used for piping? If there is not any particular purpose to use them, 
change the delimiter characters.

Second question: why do you need 2 separator? Depending on data format 
for each field you can choose a valid single delimiter and if your data 
format put you in the situation to use multiple character separator you 
should use a database (SQlite) and not a simple file.

Over this I'm not a bash guru but this can help:

echo " 34 + 45 \| abc \| 1 2 3 \| c\|123abc " | awk 'BEGIN {FS="|"} 
{for(i=1;i<=NF;i++)print $i}' | sed -e 's/\\//g'

I don't know if you need this in a loop (loops in bash are slow) so you 
can try this in python.

# python
 >>> variable = " 34 + 45 \| abc \| 1 2 3 \| c\|123abc "
 >>> list = variable.split("\|")
 >>> print(list)
[' 34 + 45 ', ' abc ', ' 1 2 3 ', ' c', '123abc ']

Very simple and efficient (sure you can use perl, C, C++ and other).

My suggestion: when you need to work with files, permission, filesystem 
and you need to manage simple string with local tools like awk,sed,tr, 
cut....bash is powerfull. When you need to manage a catalog/database 
fullfilled by variable type of records then you need a more "advanced" 
language, you will gain in performances, flexibility, time in writing 
and less problem. Using multiple little program written in another 
language (python, C, perl) in your bash script is not so bad. Ah 
learning a new language is fantastic.

Hope that helps.

[toc] | [prev] | [next] | [standalone]

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web