For example, if dstep ... -o ... is used with find and xargs sucessful execution depends from number of processed lines (src files) - if xarg splits arguments into two bunches due to system limitation second bunch can have only one line and this causes Is a directory error.

Thus, such complex behavior is inappropriate for this argument, at least seems to me

Also, -o for directories broken since 2017 (#136). Maybe it will be easier to remove -o functionality for dirs at all?

I'm not sure I follow. Can you please specify an example of how you invoke DStep (ideally without involving other commands like find or xargs), how it behaves and how you expect it to behave.

I want to run dstep over one .h file and want to place resulting .d file into another directory.

It is need to run dstep over huge number of files. Currently I run something like:

find "$SRCDIR/src/libxxx/include/" -maxdepth 1 -xtype f -name '*.h' \
    -exec ${DSTEP} '{}' \; \
    -exec sh -c 'mv $(dirname "$0")/*.d ${LIBXXX}/source/libxxx/' {}  \;

It is because I don't know resulting .d filenames - for now I forced to know filenames by dstep or use some magic.

I'm not sure if I want to add this feature. No other similar tools (like compilers) that I'm aware of provide this.

It's also possible to pass multiple files to DStep at once. Then the -o flag will specify the output directory.

No other similar tools (like compilers) that I'm aware of provide this.

In turn, I can say that I do not know any tool in which the result type (directory or file) depends on the number of source arguments.

It's also possible to pass multiple files to DStep at once.

Strictly speaking, no. There is a system limitation of size of CLI arguments. And as soon as the xarg because of this will divide the list of files into several parts (it is smart and can split arguments into chunks to start command many times), there is a risk that in the last chunk there will be only one file and an error will occur (and I already faced with it)

Hmm, I see. I might be able to add it.

And maybe it is reasonable to remove (temporary, maybe) -o support for dirs because currently it is broken 2 years at least. I spent time to bughunting inside of my own script because this...

And maybe it is reasonable to remove (temporary, maybe) -o support for dirs because currently it is broken 2 years at least. I spent time to bughunting inside of my own script because this...

It's working for simple cases.

I had a similar problem with -o. At first it seems that dstep ignored my -o param.
I was trying to use dstep with an absolute path, and this probably confuse it.

For example:

dstep -o /tmp/binding /usr/local/include/mylib/*.h

This tries to write .d files inside the "source" directory rather than on /tmp/bindings.
It turns out that using a symlink + relative path did the trick. So:

mkdir /tmp/binding/output
ln -s /usr/local/include/mylib /tmp/binding/mylib
cd /tmp/binding
dstep -o /tmp/binding/output mylib/*.h

This works for me.