I have the following line which is not working in ksh but works fine in sh:

cat `find /home/peter/databases -name "cells.txt"`

This is working if this line is inside /usr/bin/sh script. But not when it is inside /usr/bin/ksh.

Any hint why this is so?

I am using:

SUSE Linux Enterprise Server 11 (x86_64)

"Not working" means the script hangs (something like the behaviour if cat is not provided with the file name as parameter)

The output of find /home/peter/databases -name "cells.txt" is NOT empty in the ksh script. In this case, the script is able to list the found files. But the problem comes if I try catting the found files using back quotes as mentioned above.

There are nearly 1000 files listed with find command, but most of them are empty. The above said cat command is working in sh but not in ksh.

  • There are no files with the name spaces including in them.
  • The content of the file cells.txt is either empty or single statement.
  • The command (cat `find /home/peter/databases -name "cells.txt"`) works fine if the number of files under /home/peter/databases are less. In this case the number of files is 1000.
  • The same command is working in SUSE 11.3 ksh. But fails if I execute it under SUSE 11.4.
  • I kept only few files with the name cells.txt in the directories under /home/peter/databases, the command is working perfectly fine. When the files with the name cells.txt grows to a number of about 1000 then the command doesn't give any output(hangs). I suspect is it because of some buffer used for the output back quote? (``) Because the SUSE 11.3 doesn't have any issue but 11.4 hangs.
  • The command worked with the option -size +0 along with find. Is it indicating again that something about buffer?
  • 7
    What happens when it "doesn't work"? Error messages? Unexpected output? No output? Please be precise (and edit the answers into your question for all to see.) Commented Dec 16, 2015 at 11:02
  • 2
    If it hangs, then the output of find /home/peter/databases -name "cells.txt" is empty in the ksh script.
    – muru
    Commented Dec 16, 2015 at 11:19
  • 1
    What happens when you write /bin/cat? Note that catis a ksh builtin.
    – schily
    Commented Dec 16, 2015 at 11:43
  • 1
    @SSHegde What's the output of echo `find /home/peter/databases -name "cells.txt"` in the script?
    – muru
    Commented Dec 16, 2015 at 11:48
  • 1
    Oh. So the shell is taking time to build the argument list using the output of find, which you say is nearly a thousand files. Use find's -exec with cat, instead.
    – muru
    Commented Dec 16, 2015 at 11:53

2 Answers 2


Try this as an alternative solution, which will invoke cat only when it finds a file

find /home/peter/databases -type f -name 'cells.txt' -exec cat {} +

(If your version of find does not understand the trailing +, replace it with the two characters \;)

  • The solution works perfectly fine. Thank you. But why not with my way? What was wrong? :o(
    – SS Hegde
    Commented Dec 16, 2015 at 11:56
  • 2
    @SSHegde for your version if there were no files found, the cat would run with no list of files, default to reading stdin, and wait to copy whatever you typed. Your version would also fail to cat files whose names contained a space. Commented Dec 16, 2015 at 16:15
  • please see my EDIT 4
    – SS Hegde
    Commented Dec 16, 2015 at 17:27
  • 1
    @SSHegde different shells may have different buffer lengths for long command lines. It seems that for one shell you can fit all the filenames, but for the other it overflows. Commented Dec 16, 2015 at 18:35

The script worked by ignoring the file sizes of zero in find command. (-size +0)

 cat `find /home/peter/databases -name "cells.txt" -size +0`

I agree with the other solution also. But since my question was to find the reason why the ksh is unable to process the cat was because of the buffer size (output of back quote), i am posting my answer. @wurtel: Thank you. your suggestion solved the issue.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .