Roy Smith writes:
> I once knew a guy who linked /dev/tty.c to /dev/tty, then he could do
> "cc /dev/tty.c" and type a C program in to the compiler from the
> terminal.
I thought some old C compilers took input from stdin without that kind
of trickery? Oh, looks like modern gcc does it too, as
In article ,
Tim Chase wrote:
> On 2014-07-09 01:24, Chris Angelico wrote:
> > On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase
> > > Okay, EOF is the canonical way to tell a program reading stdin
> > > that you're done. It just happens that EOF ^D on *nix-likes and
> > > ^Z on Win32. :-)
> > >
> > >
On Wed, Jul 9, 2014 at 2:40 AM, Tim Chase wrote:
> On 2014-07-09 01:24, Chris Angelico wrote:
>> I can't think of any Windows-native programs that ask for EOF. Only
>> those which came from POSIX platforms do it. That said, though,
>> Windows doesn't tend to encourage interactive command-line prog
On 2014-07-09 01:24, Chris Angelico wrote:
> I can't think of any Windows-native programs that ask for EOF. Only
> those which came from POSIX platforms do it. That said, though,
> Windows doesn't tend to encourage interactive command-line programs
> at all, so you may as well just follow the Unix
On 2014-07-08, Tim Chase wrote:
> On 2014-07-09 01:49, Chris Angelico wrote:
>> Have you ever used COPY CON to create a binary file?
>
> No, for that I used DEBUG.EXE (or DEBUG.COM on older versions of DOS)
Both.
--
Jan v/d Broek
ba
On Wed, Jul 9, 2014 at 1:57 AM, Tim Chase wrote:
> On 2014-07-09 01:49, Chris Angelico wrote:
>> Have you ever used COPY CON to create a binary file?
>
> No, for that I used DEBUG.EXE (or DEBUG.COM on older versions of DOS)
I never used a DOS version so old it had DEBUG.COM, but I used
DEBUG.EXE
On 2014-07-09 01:49, Chris Angelico wrote:
> Have you ever used COPY CON to create a binary file?
No, for that I used DEBUG.EXE (or DEBUG.COM on older versions of DOS)
-tkc
--
https://mail.python.org/mailman/listinfo/python-list
On Wed, Jul 9, 2014 at 1:46 AM, Tim Chase wrote:
> On 2014-07-09 01:24, Chris Angelico wrote:
>> On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase
>> > Okay, EOF is the canonical way to tell a program reading stdin
>> > that you're done. It just happens that EOF ^D on *nix-likes and
>> > ^Z on Win32. :-)
On 2014-07-09 01:24, Chris Angelico wrote:
> On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase
> > Okay, EOF is the canonical way to tell a program reading stdin
> > that you're done. It just happens that EOF ^D on *nix-likes and
> > ^Z on Win32. :-)
> >
> > -tkc
>
> I can't think of any Windows-native p
On Wed, Jul 9, 2014 at 1:20 AM, Tim Chase wrote:
> On 2014-07-08 11:08, Terry Reedy wrote:
>> > Indeed. Ctrl-D is _the_ canonical way to tell a program that's
>> > reading stdin that your're done.
>>
>> Not on Windows.
>
> Okay, EOF is the canonical way to tell a program reading stdin that
> you'
On 2014-07-08 11:08, Terry Reedy wrote:
> > Indeed. Ctrl-D is _the_ canonical way to tell a program that's
> > reading stdin that your're done.
>
> Not on Windows.
Okay, EOF is the canonical way to tell a program reading stdin that
you're done. It just happens that EOF ^D on *nix-likes and ^Z
On 7/8/2014 10:19 AM, Grant Edwards wrote:
On 2014-07-07, Gregory Ewing wrote:
Terry Reedy wrote:
Avoid EOFError. Much better, I think, is the somewhat customary
s = input("Enter something, or hit to exit")
if not s: sys.exit()
else:
I beg to differ -- on Unix, Ctrl-D *is* the customary
w
On 7/7/2014 7:10 PM, Mark Lawrence wrote:
On 07/07/2014 23:09, Gregory Ewing wrote:
Marko Rauhamaa wrote:
with open(path) as f:
...
If the open() call is guarded against exceptions (as it usually should),
one must revert to the classic syntax:
Hmmm, maybe we could do with a with-
On 2014-07-07, Gregory Ewing wrote:
> Terry Reedy wrote:
>> Avoid EOFError. Much better, I think, is the somewhat customary
>>
>> s = input("Enter something, or hit to exit")
>> if not s: sys.exit()
>> else:
>
> I beg to differ -- on Unix, Ctrl-D *is* the customary
> way to exit from something
On Tue, Jul 8, 2014 at 7:03 PM, Steven D'Aprano wrote:
> On Mon, 07 Jul 2014 14:49:56 -0400, Terry Reedy wrote:
>
>> Avoid EOFError. Much better, I think, is the somewhat customary
>>
>> s = input("Enter something, or hit to exit") if not s:
>> sys.exit()
>> else:
>
> Under many circumstances, I
On Mon, 07 Jul 2014 14:49:56 -0400, Terry Reedy wrote:
> Avoid EOFError. Much better, I think, is the somewhat customary
>
> s = input("Enter something, or hit to exit") if not s:
> sys.exit()
> else:
Under many circumstances, I would do exactly that. But sometimes an empty
string is valid da
On Tue, Jul 8, 2014 at 3:40 AM, Marko Rauhamaa wrote:
> Chris Angelico :
>
>> if you always break everything out to keep exception-catching scope as
>> narrow as possible, you begin to lose readability in other ways.
>
> I've begun to wonder if there might exist a new, easier-to-read
> try-except
In article ,
Chris Angelico wrote:
> On Mon, Jul 7, 2014 at 10:39 PM, Roy Smith wrote:
> > $ stty -e
[...]
> Not sure what you're running, but 'stty -e' throws an error for me
> (Debian Wheezy).
That was on OSX.
--
https://mail.python.org/mailman/listinfo/python-list
In article ,
Chris Angelico wrote:
> I love how Unix will happily let you unlink a file and keep using it.
> Sure, it's a pitfall for people who are trying to figure out where on
> earth their disk space has gone ("I deleted that huge file, but my
> disk's still full!!"), but it's soo much e
In article <53bae1db$0$29995$c3e8da3$54964...@news.astraweb.com>,
Steven D'Aprano wrote:
> While I agree with the general idea that try blocks should be as narrow
> *as reasonable*, they shouldn't be as narrow *as possible* since one can
> start guarding against unreasonable things.
I'm more
On 07/07/2014 23:09, Gregory Ewing wrote:
Marko Rauhamaa wrote:
with open(path) as f:
...
If the open() call is guarded against exceptions (as it usually should),
one must revert to the classic syntax:
Hmmm, maybe we could do with a with-except statement:
with open(path) as f
Marko Rauhamaa wrote:
with open(path) as f:
...
If the open() call is guarded against exceptions (as it usually should),
one must revert to the classic syntax:
Hmmm, maybe we could do with a with-except statement:
with open(path) as f:
...
except IOError:
# Catch
Terry Reedy wrote:
Avoid EOFError. Much better, I think, is the somewhat customary
s = input("Enter something, or hit to exit")
if not s: sys.exit()
else:
I beg to differ -- on Unix, Ctrl-D *is* the customary
way to exit from something that's reading from stdin.
In any case, you need to be
Roy Smith wrote:
We've since modified our cleanup script to run lsof and skip purging any
releases which are still in use :-)
Or, if you're on Unix, make sure you open all the files
you're likely to need at the beginning and hold onto
them. :-)
--
Greg
--
https://mail.python.org/mailman/listin
On 7/7/2014 8:39 AM, Roy Smith wrote:
On a different topic, I've always disliked embedding instructions to
"type Ctrl-D". The problem is, how to generate an EOF (or interrupt, or
whatever) is configurable in the tty driver (see below). In theory, the
user could have remapped EOF to be somethin
Steven D'Aprano :
> try:
> f = open(path)
> except Whatever:
> handle_error()
> else:
> with f:
> do_stuff()
That's cool. Never really used try-else.
> That gets old really quickly! But then, handling errors is always the
> ugliest part of coding. Hiding the messy details ins
On Mon, 07 Jul 2014 20:31:53 +0300, Marko Rauhamaa wrote:
> If the open() call is guarded against exceptions (as it usually should),
> one must revert to the classic syntax:
>
> try:
> f = open(path)
> except IOError:
> ...
> try:
> ...
> finally:
>
Chris Angelico :
> if you always break everything out to keep exception-catching scope as
> narrow as possible, you begin to lose readability in other ways.
I've begun to wonder if there might exist a new, easier-to-read
try-except syntax.
Marko
--
https://mail.python.org/mailman/listinfo/pyth
Ian Kelly :
> It's good practice to keep your try blocks as narrow as possible in
> any case.
True. Unfortunately, that leads to trouble with the handy "with"
construct:
with open(path) as f:
...
If the open() call is guarded against exceptions (as it usually should),
one must rever
On Tue, Jul 8, 2014 at 3:25 AM, Ian Kelly wrote:
> On Mon, Jul 7, 2014 at 2:09 AM, Chris Angelico wrote:
>> But if the code's more complicated and it's not so easy to split, then
>> sure, doesn't seem a problem. It's like spam[foo//bar] and then
>> catching either IndexError or ZeroDivisionError
On Mon, Jul 7, 2014 at 2:09 AM, Chris Angelico wrote:
> But if the code's more complicated and it's not so easy to split, then
> sure, doesn't seem a problem. It's like spam[foo//bar] and then
> catching either IndexError or ZeroDivisionError - there's no big
> confusion from having two distinct s
Marko Rauhamaa :
> input() quite naturally can raise an IOError. For example:
>
> import os, socket
> s = socket.socket(socket.AF_UNIX)
> s.bind("xyz")
> os.dup2(s.fileno(), 0); print(input())
>
> results in an IOError (EINVAL, to be exact).
Even simpler:
>>> import os
>>>
Steven D'Aprano :
> On Mon, 07 Jul 2014 22:19:20 +1000, Chris Angelico wrote:
>
>> It's possible for input() to raise IOError, if I'm not mistaken;
>> consider redirection, for instance.
>
> What indirection? Do you mean, if built-in input() has been monkey-
> patched? Well, sure, but in that case
On 7/7/14, Mark Lawrence wrote:
> On 07/07/2014 09:09, Chris Angelico wrote:
>> On Mon, Jul 7, 2014 at 6:00 PM, Steven D'Aprano
>> wrote:
>>> How do people feel about code like this?
>>>
>>> try:
>>> name = input("Enter file name, or Ctrl-D to exit")
>>> # On Windows, use Ctrl-Z [enter]
On Tue, Jul 8, 2014 at 1:45 AM, Steven D'Aprano
wrote:
> On Mon, 07 Jul 2014 22:19:20 +1000, Chris Angelico wrote:
>
>> It's possible for input() to raise IOError, if I'm not mistaken;
>> consider redirection, for instance.
>
> What indirection? Do you mean, if built-in input() has been monkey-
>
On Mon, 07 Jul 2014 22:19:20 +1000, Chris Angelico wrote:
> It's possible for input() to raise IOError, if I'm not mistaken;
> consider redirection, for instance.
What indirection? Do you mean, if built-in input() has been monkey-
patched? Well, sure, but in that case it could do anything. I'm on
On Mon, Jul 7, 2014 at 11:06 PM, Mark Lawrence wrote:
>> try:
>> name = input("Enter file name, or Ctrl-D to exit")
>> # On Windows, use Ctrl-Z [enter] instead.
>> except EOFError:
>> sys.exit()
>> try:
>> fp = open(name)
>> except IOError:
>> handle_bad_file(name)
>> else
On Mon, Jul 7, 2014 at 11:06 PM, Mark Lawrence wrote:
> On 07/07/2014 09:09, Chris Angelico wrote:
>>
>> It seems trivial in this example to break it into two try blocks:
>>
>> try:
>> name = input("Enter file name, or Ctrl-D to exit")
>> # On Windows, use Ctrl-Z [enter] instead.
>> exce
On 07/07/2014 09:09, Chris Angelico wrote:
On Mon, Jul 7, 2014 at 6:00 PM, Steven D'Aprano wrote:
How do people feel about code like this?
try:
name = input("Enter file name, or Ctrl-D to exit")
# On Windows, use Ctrl-Z [enter] instead.
fp = open(name)
except EOFError:
sys.
On Mon, Jul 7, 2014 at 10:46 PM, Roy Smith wrote:
> We've since modified our cleanup script to run lsof and skip purging any
> releases which are still in use :-)
LOL!
I have a computer on which I periodically build and install new
versions of a few pieces of software. Most of them don't keep ru
On Mon, Jul 7, 2014 at 10:39 PM, Roy Smith wrote:
> $ stty -e
> speed 9600 baud; 24 rows; 80 columns;
> lflags: icanon isig iexten echo echoe -echok echoke -echonl echoctl
>-echoprt -altwerase -noflsh -tostop -flusho pendin -nokerninfo
>-extproc
> iflags: -istrip icrnl -inlcr -igncr ixon -
In article ,
Chris Angelico wrote:
> On Mon, Jul 7, 2014 at 6:00 PM, Steven D'Aprano wrote:
> > How do people feel about code like this?
> >
> > try:
> > name = input("Enter file name, or Ctrl-D to exit")
> > # On Windows, use Ctrl-Z [enter] instead.
> > fp = open(name)
> > except E
In article <53ba538d$0$2926$c3e8da3$76491...@news.astraweb.com>,
Steven D'Aprano wrote:
> On Mon, 07 Jul 2014 17:04:12 +1200, Gregory Ewing wrote:
>
> > Steven D'Aprano wrote:
> >> Are there any circumstances where merely *opening* a file (before
> >> reading it) can raise EOFError?
> >
> > I
On Mon, Jul 7, 2014 at 6:00 PM, Steven D'Aprano wrote:
> How do people feel about code like this?
>
> try:
> name = input("Enter file name, or Ctrl-D to exit")
> # On Windows, use Ctrl-Z [enter] instead.
> fp = open(name)
> except EOFError:
> sys.exit()
> except IOError:
> hand
Steven D'Aprano Wrote in message:
> On Mon, 07 Jul 2014 17:04:12 +1200, Gregory Ewing wrote:
>
>> Steven D'Aprano wrote:
>>> Are there any circumstances where merely *opening* a file (before
>>> reading it) can raise EOFError?
>>
>> I don't think so. As far as I know, the only built-in thing tha
On Mon, Jul 7, 2014 at 6:00 PM, Steven D'Aprano wrote:
> How do people feel about code like this?
>
> try:
> name = input("Enter file name, or Ctrl-D to exit")
> # On Windows, use Ctrl-Z [enter] instead.
> fp = open(name)
> except EOFError:
> sys.exit()
> except IOError:
> hand
On Mon, 07 Jul 2014 17:04:12 +1200, Gregory Ewing wrote:
> Steven D'Aprano wrote:
>> Are there any circumstances where merely *opening* a file (before
>> reading it) can raise EOFError?
>
> I don't think so. As far as I know, the only built-in thing that raises
> EOFError is input() (and raw_inpu
Steven D'Aprano wrote:
Are there any circumstances where merely *opening* a file (before reading
it) can raise EOFError?
I don't think so. As far as I know, the only built-in
thing that raises EOFError is input() (and raw_input()
in Py2).
--
Greg
--
https://mail.python.org/mailman/listinfo/py
Are there any circumstances where merely *opening* a file (before reading
it) can raise EOFError?
--
Steven
--
https://mail.python.org/mailman/listinfo/python-list
49 matches
Mail list logo
