Surprising behavior for commands in Unix shell

[emeryberger]

$ ls -ltra
/usr/bin/ls: [object Object]$ 

[bpowers]

A couple of issues here.

• [x] error is being stringified, rather than accessing error.message
• [x] no newline on end of error message
• [x] in fact, we shouldn't be hitting a fs error, because we should be parsing -ltra as 4 1-char arguments.
• [ ] All commands should provide a -h option to get a list of valid options.

I've fixed the first 3 issues in 81a04c692 for ls, but this needs to be updated & standardized for all the commands.

[bpowers]

Going to leave this open as a tracking issue until all commands are fixed.

[jvilk]

Do the error objects not have a toString()? (And whose error objects are they?)

[jvilk]

(BrowserFS error objects have toString() defined to return error.message)

[bpowers]

@jvilk they start as BrowserFS errors, but when they are transferred to the Worker the prototype is stripped thanks to the structured cloning algorithm :\

Right before postMessage to worker:

After worker gets the message:

[bpowers]

I guess I should detect if we've received something like an ApiError and replace the received object with a new ApiError