On 12/14/2016 09:29 PM, Samuel Williams wrote:
> Here are some examples of different languages:
>
> https://github.com/ioquatix/script-runner/blob/master/examples/python-eot.py
Okay so it looks like you're just opening a pipe to a subprocess and
feeding it a script and input. So there's no pty i
Here are some examples of different languages:
https://github.com/ioquatix/script-runner/blob/master/examples/python-eot.py
--
https://mail.python.org/mailman/listinfo/python-list
On Thu, 15 Dec 2016 01:28 am, Random832 wrote:
> On Tue, Dec 13, 2016, at 19:10, Steve D'Aprano wrote:
>> Can you show a simple demonstration of what you are doing?
>>
>> I'm having difficulty following this thread because I don't know
>> what "script run on a tty" means.
>
> The question is lit
On Tue, Dec 13, 2016, at 19:20, Steve D'Aprano wrote:
> sys.flags.interactive will tell you whether or not your script was
> launched
> with the -i flag.
>
> hasattr(sys, 'ps1') or hasattr(sys, 'ps2') will tell you if you are
> running
> in the REPL (interactive interpreter). The ps1 and ps2 varia
On Tue, Dec 13, 2016, at 19:10, Steve D'Aprano wrote:
> Can you show a simple demonstration of what you are doing?
>
> I'm having difficulty following this thread because I don't know
> what "script run on a tty" means.
The question is literally about the input/script being the tty and not
redire
Steve D'Aprano writes:
> I thought that with the exception of scripts run from cron, any time
> you run a script *or* in interactive mode, there is an associated tty.
> Am I wrong?
Any daemon will, by definition, have no controlling terminal.
Other processes can choose to detach themselves from
On 12/13/2016 05:10 PM, Steve D'Aprano wrote:
> Can you show a simple demonstration of what you are doing?
I think they want to run Python, perhaps remotely via ssh, and feed it
both a script and input over standard-in (though a tty comes into this
somehow and I'm not clear on that). Apparently i
On Wed, 14 Dec 2016 04:48 am, Random832 wrote:
> On Tue, Dec 13, 2016, at 11:01, Michael Torrie wrote:
>> On 12/13/2016 05:39 AM, Samuel Williams wrote:
>> > Michael, yes.
>> >
>> > FYI, I found out why this works. Pressing Ctrl-D flushes the input
>> > buffer. If you do this on an empty line, it
On Wed, 14 Dec 2016 09:24 am, Random832 wrote:
> On Tue, Dec 13, 2016, at 17:09, Michael Torrie wrote:
>> On 12/13/2016 10:48 AM, Random832 wrote:
>> > The problem is there's currently no way to differentiate "interactive
>> > mode" from "script run on a tty".
>> >
>> > You can get similar behavi
On Tue, Dec 13, 2016, at 17:09, Michael Torrie wrote:
> On 12/13/2016 10:48 AM, Random832 wrote:
> > The problem is there's currently no way to differentiate "interactive
> > mode" from "script run on a tty".
> >
> > You can get similar behavior with python -c "import
> > sys;exec(sys.stdin.read()
On 12/13/2016 10:48 AM, Random832 wrote:
> The problem is there's currently no way to differentiate "interactive
> mode" from "script run on a tty".
>
> You can get similar behavior with python -c "import
> sys;exec(sys.stdin.read())"
Are you sure? I can pipe scripts into Python and they run fine
On Tue, Dec 13, 2016, at 11:01, Michael Torrie wrote:
> On 12/13/2016 05:39 AM, Samuel Williams wrote:
> > Michael, yes.
> >
> > FYI, I found out why this works. Pressing Ctrl-D flushes the input
> > buffer. If you do this on an empty line, it causes read(...) to return
> > 0 which Ruby considers
On 12/13/2016 09:01 AM, Michael Torrie wrote:
> On 12/13/2016 05:39 AM, Samuel Williams wrote:
>> Michael, yes.
>>
>> FYI, I found out why this works. Pressing Ctrl-D flushes the input
>> buffer. If you do this on an empty line, it causes read(...) to return
>> 0 which Ruby considers end of input f
On 12/13/2016 05:39 AM, Samuel Williams wrote:
> Michael, yes.
>
> FYI, I found out why this works. Pressing Ctrl-D flushes the input
> buffer. If you do this on an empty line, it causes read(...) to return
> 0 which Ruby considers end of input for the script, but the pipe is
> not closed.
Curren
Michael, yes.
FYI, I found out why this works. Pressing Ctrl-D flushes the input
buffer. If you do this on an empty line, it causes read(...) to return
0 which Ruby considers end of input for the script, but the pipe is
not closed.
--
https://mail.python.org/mailman/listinfo/python-list
On 12/09/2016 06:43 PM, Steve D'Aprano wrote:
> On Sat, 10 Dec 2016 10:11 am, space.ship.travel...@gmail.com wrote:
>
>> Hello.
>>
>> I'm working on a script runner for Atom.
>>
>> https://github.com/ioquatix/script-runner
>>
>> We are trying to understand how to make python work well. I'll use a
On Sat, 10 Dec 2016 10:11 am, space.ship.travel...@gmail.com wrote:
> Hello.
>
> I'm working on a script runner for Atom.
>
> https://github.com/ioquatix/script-runner
>
> We are trying to understand how to make python work well. I'll use a
> comparison to the ruby executable because it's conve
Just in case it's not clear, this is running on a (virtual) PTY.
--
https://mail.python.org/mailman/listinfo/python-list
On 12/09/2016 04:11 PM, space.ship.travel...@gmail.com wrote:
> When you invoke `ruby` from a pty, you get no output (as opposed to
> `irb`, interactive ruby [shell]). You can write a script to stdin,
> and send Ctrl-D (EOT / 0x04). Then, ruby will execute the script.
> stdin is not closed so progr
On 12/09/2016 04:11 PM, space.ship.travel...@gmail.com wrote:
> Hello.
>
> I'm working on a script runner for Atom.
>
> https://github.com/ioquatix/script-runner
>
> We are trying to understand how to make python work well. I'll use a
> comparison to the ruby executable because it's convenient t
Hello.
I'm working on a script runner for Atom.
https://github.com/ioquatix/script-runner
We are trying to understand how to make python work well. I'll use a comparison
to the ruby executable because it's convenient to explain the problem.
When you invoke `ruby` from a pty, you get no output
21 matches
Mail list logo
