I can replicate on Linux. With an empty con dir in current dir, debugger does not break until program exits. If ./con is a file, it writes to it and enters some kind of never-ending loop, as you say.
strace perl -d a.pl shows this:
newfstatat(AT_FDCWD, "con", ..., ...)Then, if con is found, it is opened with openat(AT_FDCWD, "con", O_RDWR|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) and it is writing to it.
perl a.pl does not look for con
The flag AT_FDCWD has the meaning of "relative to current dir", i.e. where you execute from and not where script is located.
documentation mentions it:
If there is a TTY, we have to determine who it belongs to before we ca +n proceed. If this is a slave editor or graphical debugger (denoted b +y the first command-line switch being '-emacs'), we shift this off an +d set $rl to 0 (XXX ostensibly to do straight reads). We then determine what the console should be on various systems: Cygwin - We use stdin instead of a separate device. Windows or MSDOS - use con. AmigaOS - use CONSOLE:. VMS - use sys$command. Unix - use /dev/tty.
Question is: why on Unix con has a role?
And I find this in source of perl5db.pl:
elsif ( $^O eq 'dos' or -e "con" or $^O eq 'MSWin32' ) { $console = "con"; }
-e "con" short-circuits the Unix check further down (if file or dir "con" exists in current dir): if( -e '/dev/tty'). Surely a bug AFAICS.
bw, bliako
In reply to Re^2: perl -d myprog autostarts - but only in one specific directory
by bliako
in thread perl -d myprog autostarts - but only in one specific directory
by ibm1620
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |