[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-bash] Substring Replacement
From: |
Richard Taubo |
Subject: |
Re: [Help-bash] Substring Replacement |
Date: |
Fri, 30 May 2014 20:53:02 +0200 |
On May 30, 2014, at 8:25 PM, Greg Wooledge <address@hidden> wrote:
> On Fri, May 30, 2014 at 08:08:21PM +0200, Richard Taubo wrote:
>> I have solution working like this (thanks to input from this list earlier):
>> while IFS= read -r -d "" path; do
>> echo -n "<li><ul>"
>> echo -n "${path//\//<li>}"
>> echo -n"</ul></li>"
>> echo -n "</ul>"
>> done < <(find my_directory -print0)
>>
>>
>> It works fine, but I am measuring if I can get a little speed boost by doing
>> something like this:
>> find my_directory -print0 | /usr/bin/xargs -0 -I {} /bin/echo
>> "<li><ul>"${IS_IT_POSSIBLE_TO_PICK_UP_ECHO_VALUE_HERE//\//<li>}"</ul></li>"
>
> Well, forking /bin/echo for each file & directory is definitely not
> going to improve speed.
> The short answer is "No, in your sample code, there is no shell to interpret
> the ${...} and perform an expansion." The input data is only available to
> xargs, and then to the command spawned by xargs. /bin/echo doesn't do
> expansions.
> If you want to perform an expansion at that point, you would need to
> have an xargs option to perform generalized substitutions (I don't know
> of any such xargs extensions), or you would need to have xargs launch
> a shell which can interpret the ${...}. Which would basically lead you
> right back to your working code example, only slower.
OK, thanks.
> A different approach would be to let sed do the search-and-replace,
> instead of doing it in the shell:
>
> while IFS= read -r -d "" path; do
> echo -n "<li><ul>"
> echo -n "${path}"
> echo -n"</ul></li>"
> echo -n "</ul>"
> done < <(find my_directory -print0 | sed 's#/#<li>#g')
>
> Though personally I'd write it this way:
>
> while IFS= read -r -d "" path; do
> printf '<li><ul>%s</ul></li></ul>\n' "$path"
> done < <(find my_directory -print0 | sed 's#/#<li>#g')
OK, thanks, I will be testing which is faster and go with that.
## My testing shows that for the test case:
Your version clocked in at: 0m3.951s
and my at: 0m4.273s
So I will go with yours :-)
> I added \n because I hate when I view HTML source code and it's all one
> gigantic line. I think you're missing a <ul> in front of it, too.
As this is internal in a program, no one will see it, but I guess the extra \n
doesn't hurt. The starting <ul> would be added separately, so the extra "</ul>"
was mistakenly added to the while loop here.
Thanks for the feedback!
Best regards,
Richard Taubo