Re: How to specify a Null char in a match operation

It's not so much that you aren't able to generate a string or detect the null, it is more likely that things go awry in subsequent processing. Consider:

use strict;
use warnings;

my @strs = ("filename1.txt\0", "filename2\0.txt", "filename3.txt");

/\0/ && ((print "Null char detected in >$_<"), print "\n") for @strs;
[download]

Prints:

Null char detected in >filename1.txt
Null char detected in >filename2
[download]

Note that print has truncated the strings at the null character. A sign that C is at work under the hood.

DWIM is Perl's answer to Gödel

Comment on Re: How to specify a Null char in a match operation Select or Download Code

Replies are listed 'Best First'.
Re^2: How to specify a Null char in a match operation by shmem (Chancellor) on Oct 11, 2006 at 09:28 UTC
No, print doesn't truncate at \0 chars. I guess that's platform specific (you're on Windows?). Try `use strict; use warnings; binmode STDOUT; my @strs = ("filename1.txt\0", "filename2\0.txt", "filename3.txt"); /\0/ && ((print "Null char detected in >$_<"), print "\n") for @strs;` [download] If you still see truncated strings, it might be the terminal's fault. On linux, piping the output to a pager, I see `Null char detected in >filename1.txt^@< Null char detected in >filename2^@.txt<` [download] --shmem _($_=" "x(1<<5)."?\n".q·/)Oo. G°\ / /\_¯/(q / ---------------------------- \__(m.====·.(_("always off the crowd"))."· ");sub _{s./.($e="'Itrs `mnsgdq Gdbj O`qkdq")=~y/"-y/#-z/;$e.e && print}	[reply] [d/l] [select]
Re^3: How to specify a Null char in a match operation by swampyankee (Parson) on Oct 11, 2006 at 19:58 UTC
With shmem's code, I get this output in a Windows command shell: `Null char detected in >filename1.txt < Null char detected in >filename2 .txt<` [download] and replicate shmem's output when going through emacs. emc At that time [1909] the chief engineer was almost always the chief test pilot as well. That had the fortunate result of eliminating poor engineering early in aviation. —Igor Sikorsky, reported in AOPA Pilot magazine February 2003.	[reply] [d/l]
Re^2: How to specify a Null char in a match operation by ikegami (Patriarch) on Oct 14, 2006 at 07:58 UTC
What Perl and OS are you using? With ActivePerl 5.6.1, 5.8.0 and 5.8.8 all print the following in WinXP. `Null char detected in >filename1.txt < Null char detected in >filename2 .txt<` [download] I even confirmed the "space" is a `NUL`.	[reply] [d/l] [select]
Re^3: How to specify a Null char in a match operation by GrandFather (Saint) on Oct 14, 2006 at 10:37 UTC
Turns out it is a problem with Komodo's output window. My appologies for any time wasted with chasing this! DWIM is Perl's answer to Gödel	[reply]
Re^2: How to specify a Null char in a match operation by Nik (Initiate) on Oct 11, 2006 at 09:15 UTC
Thank you iam trying to understand it but i cant, especially the part tha the .txt will not be showed and why the '<' isnt showed also. Can you plz clarify some more?	[reply]
Re^3: How to specify a Null char in a match operation by bart (Canon) on Oct 11, 2006 at 11:07 UTC
Like he said, it uses C under the hood. Now C doesn't store the length of a string anywhere. Instead, each time, it scans the string (which is just an array of characters, of unspecified length) looking for a special "end of string" character. And that character is chr(0). So when C is processing the string, it just stops when it sees a chr(0). And the way it does that, is hideously simple: the value of the character, which in C is pretty much a small integer, when taken as a boolean value(= true or false), is false — as an integer it's 0. All other characters are nonzero, thus true. This character is not special in Perl, because Perl does store the length of each string somewhere. And yes, IMnshO this is a serious shortcoming in C.	[reply]
Re^4: How to specify a Null char in a match operation by demerphq (Chancellor) on Oct 11, 2006 at 12:31 UTC
C doesn't store the length of a string anywhere. C doesnt have a string type at all. And IMO null-terminated character arrays have proven to be the most expensive design-fault in the entire history of computing, costing billions per year. In this respect I think that history has proven that Wirth was right and the Kernigham and Ritchie were wrong. Which I guess makes 1 for 30 or something :-) --- $world=~s/war/peace/g	[reply]