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 |