STDIN in test is bound to the calling terminal STDIN when Data block not specified

[UnasZole]

Hi,

I just noticed a behaviour on 0.28.1 which seems wrong to me.

Simply put, I'm defining a helper function "readParameter", which requires quite a lot of input before just calling the application under test.
The basic part of that input (parameter name...), I'm passing as actual arguments.
The most structured part (some context information) I pass using a Data block.
The readParameter function then consumes the full STDIN (ie the contents of the data block), typically with stdin=$(cat).

It works fine overall.

In some cases, however, I don't need to pass any context.
If I just pass an empty Data block, like this

It 'does stuff'
    Data
    End
    When call readParameter parameterWithoutContext
    The output should equal 'default'
End

It still works fine.

But if I remove the Data block entirely, like this :

It 'does stuff'
    When call readParameter parameterWithoutContext
    The output should equal 'default'
End

Then, shellspec hangs on the test, until I type ctrl+D in my terminal (and then hangs on the next such test, etc.).
Which implies that the test is actuall waiting on the terminal's STDIN.

Given that shellspec aims at running automated tests anyway, I would not expect the running test to be tied to the terminal's STDIN.
It would be more natural to me if omitting the data block entirely was identical to passing an empty one, ie sending an empty string via STDIN.

Was this behaviour decided on purpose for some use cases I'm missing, or could it be changed/fixed ?

[LukeSavefrogs]

It's not an error. It is how shells work.

If the function (readParameter) expects data to be passed to stdin, then it will hang forever until an End-Of-File character is received (Ctrl+D).

If you need a default if no stdin is passed then it's exactly THAT the problem. The test shows that the function does not work as you intend, so you must handle it in the readParameter code

[UnasZole]

Please read the title of the ticket again. The issue I'm complaining about is not "the call hangs waiting for stdin", which is indeed normal if using the stdin from the terminal.

What I'm saying is that in my opinion, shellspec SHOULD NOT be forwarding the terminal's stdin to the call in the first place.

For a tool designed to build automatable and reproducible test suites, plugging terminal stdin into the processing of individual tests is a weird design choice at best, and a bug at worst (tests results may change if the impatient user presses any key on his terminal while the campaign progresses).

Again, all I'm saying is that when no Data block is specified, the "call" stdin should receive an empty string, and NOT the terminal's stdin.
In other words, no Data block should be equivalent to an empty Data block.

If there really are use cases where it makes sense to forward the calling terminal stdin to the test functions, I'm very curious to read about it.
And even if there are :

• It may be more reliable to disable that binding by default, and provide a way to enable it explicitly,
• And most importantly, this behaviour should be explicitly specified and documented.