The following setup does not work, although it should (at it might have in older versions):
/tmp/bla/a.sol:
import "./b.sol";
----
/tmp/bla/b.sol:
contract c {}
----
solc =/tmp/x/ /tmp/bla/a.sol
@chriseth I've reduced your example to a slighly more readable format and encapsulated it in a small script to verify the error here: https://github.com/ajsantander/solc-imports-test
With it, I verify that the error exists in the following versions (non-exhaustive):
0.4.11
0.4.17
0.4.18
0.4.19
0.4.20
0.4.21
0.4.22
0.4.23
0.4.24
Which makes me wonder if this falback feature ever worked? I suggest that a test is added for it in the test suite.
I didn't really analyze this yet, but there was a change that made it into 0.4.8, so we probably have to search earlier.
Ok, I checked 0.4.7, and it seems it never worked as advertised.
As this problem was not noticed for over a year, perhaps the best solution would be to just delete the mentioning of the fallback mechanism in the documentation.
I would like to try if something like solc =/tmp/x/ /tmp/bla:/tmp/bla=/tmp/bla /tmp/bla/a.sol works, but not sure if we should recommend that.
Remappings seem to be popular and usable. The effects of =/something might be unexpected though, and certainly do not provide a fallback feature as suggested in the documentation (perhaps it would even be a security problem if they did).
Because of that I would propose to disallow an empty remapping source starting from 0.5.0.
By @axic: Documentation have its own section about remappings, because it can be used both on the commandline and the standard-json.