Skip to content

coco process stderr #168

Closed
jan-swiecki opened this Issue Sep 20, 2012 · 16 comments

3 participants

@jan-swiecki

I spawn child_process of coco. If there is an error stderr has only one line (manually executed has them more).

Example code:

# index.co
not_working_script(

# coco_test.co
cp = require 'child_process'
proc = cp.spawn 'coco.cmd', ['-c', 'index.co']

proc.stdout.on 'data', (data)->
    process.stdout.write data

proc.stderr.on 'data', (data)->
    process.stderr.write data

proc.on 'exit', (exit_code)~>
    console.log "exit"

$ coco -c index.co
Failed at: index.co
SyntaxError: missing `)CALL` on line 1

$ coco coco_test.co
Failed at: index.co
exit
@satyr
Owner
satyr commented Sep 20, 2012

Running the same thing (with "coco.cmd" → "coco") gives me:

$ coco coco_test.co
Failed at: index.co
exit
SyntaxError: missing `)CALL` on line 2

What's coco.cmd? Is this on Windows?

@jan-swiecki

Yes, forgot to mention it, sorry.

Windows XP SP3
Node 0.8.1
Coco 0.8.0

When I try to spawn "coco" I get

$ coco coco_test.co
CreateProcessW: The system cannot find the file specified.
exit

And "coco.cmd" somehow works. My windows PATH points to C:\Documents and Settings\LND\Application Data\npm where there are ".cmd" files (e.g. coco and coco.cmd)

btw. in your output shouldn't exit be last?

PS
I get the same problem in Python with subprocess module.

@satyr
Owner
satyr commented Sep 20, 2012

Windows XP SP3

nodejs/node-v0.x-archive#3871 might be related?

btw. in your output shouldn't exit be last?

Probably because Stream#write doesn't immediately flush.

Changing

proc.stderr.on 'data', (data)->
  process.stderr.write data

to

proc.stderr.pipe process.stderr

makes the exit happen last.

@vendethiel

coco -ce "foo(" > a.txt

SyntaxError: missing ')CALL' on line 1

cat a.txt

(empty)

this also applies when I try to run, say, coco -c $file from a PHP script, I can't get the error message. I have the first line, only "Failed at: $file"

@jan-swiecki

@satyr
It might be related.

Thanks for clarification about flushing.

@Nami-Doc
And I have this problem in Python too, but you are running Linux, am I right?

btw. > redirects stdout, not stderr. On windows you can do it like this:

coco -ce "foo(" > a.txt 2>&1
@vendethiel

I'm running windows 7, and the same thing happens on vista.
I'll try coco -ce "foo(" > a.txt 2>&1, but my php script is supposed to read from stderr too.
Edit : Well, it works in the cmd, but exec("coco -c $file 2>&1", $out) isn't working.
Edit : ok, got it working with > a.txt 2>&1 then reading a.txt !

@jan-swiecki

I know what could be the problem. I have encountered a similar problem with my own program spawning my other program. I did process.exit(0) after some console.log calls, but only FIRST console.log would show! It seems that console.log and process.stdout.write is asynchronous and process.exit(0) doesn't care about the output buffer.

If I executed my other program directly from command line everything was fine.

Removing process.exit(0) fixed my issue.

Related stuff

@satyr satyr added a commit that referenced this issue Sep 23, 2012
@satyr command: fixing #168 2a553b0
@satyr
Owner
satyr commented Sep 23, 2012

Thanks for the links. Can you check if that commit works?

@jan-swiecki

Yes, but now when I go back to previous version everything is working fine too. I will reboot and try again.

@jan-swiecki

It seems that your commit doesn't work now in my case. When I switch console.warn('%s\n', it); with fs.writeSync(2, it + '\n'); it works.

Anyways I would wait for @Nami-Doc to test this.

@satyr
Owner
satyr commented Sep 23, 2012

Uh huh:

coco> console.warn
[Function]
function () {
  process.stderr.write(util.format.apply(this, arguments) + '\n');
}

So apparently the console.warn hack the last link gave doesn't work (probably outdated).

@jan-swiecki

I see. To be honest I didn't focus on the first paragraph. I meant:

process.exit() will terminate node immediately, even if there are still queued writes to stdout

And I didn't test console.warn before, so I'm sorry for the confusion.

@satyr satyr added a commit that referenced this issue Sep 23, 2012
@satyr command: fixing #168 again 5dcc678
@satyr
Owner
satyr commented Sep 23, 2012

What now?

@jan-swiecki

Yes, this works :)

@vendethiel

Thanks - I'll check this ASAP

@satyr satyr closed this Sep 24, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.