Skip to main content
Unix & Linux

You are not logged in. Your edit will be placed in a queue until it is peer reviewed.

We welcome edits that make the post easier to understand and more valuable for readers. Because community members review edits, please try to make the post substantially better than how you found it, for example, by fixing grammar or adding additional resources and hyperlinks.

Required fields*

8
  • 1
    why do you think sed/awk would be slow for this purpose? They are as fast as they come. Commented Oct 26, 2014 at 3:09
  • 1
    @Ketan Sed and awk are separate processes, so they can never be fast as something that bash can do natively without launching a separate process. Normally this difference is hardly noticeable, but where performance matters in shell scripts is usually a certain loop or computation is being repeated a very large number of times, and spawning thousands of processes will be noticeably slower than doing a simple string manipulation in bash natively. Commented Oct 26, 2014 at 3:50
  • 2
    @jw013 This is true for short strings as "hello world" from the question, but if string is very long, say the tr manual, then the opposite is true because time of spawning the processes is negligible in comparison to time of string manipulation for which sed and awk are dedicated. If string is extremely long, say the whole bash manual, then bash can just refuse to proceed altogether, because of some internal limitations. Commented Oct 26, 2014 at 4:38
  • 2
    @jw013 I'm claiming that bash's string manipulation code is less efficient then dedicated tools as sed, awk, tr or similar. Look at the gena2x answer, which I edited some time ago adding exactly this information: unix.stackexchange.com/questions/162221/… you may want to compare it with terdon answer to the same question where he gives time for short strings in which case process spawning takes most time. You can test it yourself and post result. Commented Oct 26, 2014 at 5:14
  • 2
    @Miati Why would you think this extra read x; echo $x is any better for performance? The syntax does not look any shorter or cleaner. x=${x// /_}; x=${x^^} is a much more concise way to do the same thing as {read x; echo ${x.... As far as performance goes, @jimmij has pointed out that tr / sed would be faster than bash, fork count being equal. Using a pipe always results in an extra process so the argument of saving a fork no longer applies. Thus, if are using pipes, just use sed / tr etc. If you can do it in bash, do so and skip this read x; echo $x nonsense. Commented Oct 27, 2014 at 2:49