Re^6: perl 5.12 BSD portability (CPAN test result)...print

[perl-diddler]

Well it works on my machine, of course, but because of the problem report with 'say' working as a 'pre-method', but generating the exact same type of error when used as a target method, I was leaning toward trying that.

The reason being, is that let's say you have the 5.12 source -- it shouldn't be different for different platforms. So the @ISA chain should be the same and if I call print on a IO::File -- it derives from IO::Handle -- so unless object calling is completely broken on 5.12 -- which it wasn't, AFAIR. But something was bizarre with having pre-methods (verb object), work when object->verb did not in that time frame. So it would make more sense to hope the same thing that affected 'say', is affecting 'print' ??? Does that sound logical/reasonable?

I.e. if the problem mentioned with 'say' said putting those two use statements in was the solution they tried, I'd likely try it first.

I have no way to test it other than wait for more test reports to come in, unless someone knows of a way to run it more quickly...but haven't uploaded new source yet... was still dwelling on how I wanted to solve the windows case...that and working on other things while my brain 'stews'...;-)...

Later...

Uploaded V1.0.12 with the BSD and the Win fix. Of course now, every other platform will break... but hey! ;-)....ok ... maybe not linux and maybe not windows...(testing on windows in strawberry is less than fun -- no bash! I do most of my windows cmdline stuff in cygwin)...

[tobyink]

"no bash"

IIRC there's a MinGW non-Cygwin build of bash. I've also found using GNU utilities for Win32 within cmd.exe mostly acceptable, apart from the appalling implementation of tab-completion.

[syphilis]

IIRC there's a MinGW non-Cygwin build of bash

Sounds like you're thinking of msys, and it comes with 'cat' ... but not 'rev'.
Even my Cygwin shell does not provide 'rev' (though it may be available for separate download).

If you're just going to use 'cat' to spit out the contents of a file, you can use 'type' instead in cmd.exe shell:

C:\_32>type /?
Displays the contents of a text file or files.

TYPE [drive:][path]filename

C:\_32>

I don't know of any windows built-in equivalent for 'rev'.

Cheers,
Rob

[perl-diddler]

Sorta being a bit stubborn on that -- want to get a 64-bit version.

Otherwise, many things will default to 32-bit when their is a 64-bit version available unless you do perverse things w/your path -- and that causes other weirdnesses...

My terminal emulator (Terminal2) is 64-bit...as for usability of cmd.exe... I'm too used to doing in-line 1 liners -- I'd have to relearn MS's crap syntax. So many man hours wasted just on Gates trying to avoid looking like unix (via cp/m) so chose '\' -- obviously never having programmed in 'C' or most other languages... It's what happens when a marketing and idea guy designs an interface instead of a computer geek. At least internally, most of NT handles '\', and most of the Win interface used to do a better job back in the win98 days... when the command shell had an option to set the separator. Now they have backtracked -- that and a continual push to use UCS-2 (which they try to pass off as UTF-16, but isn't in most places).

Note -- You wonder why the (??) the ID3v2 spec never progressed to ID3v4 which was passed ~13 years ago? MS developers were injected into the ID3.org committee, so people couldn't move the standard to UTF-8.

Now I evidence of similar infection on the freedesktop committee and their move to 'systemd' that uses Win.INI format for config and moves by most linux distros to make the boot process binary only so it can qualify for MS-signing.

Was great that linus stood up and told them that putting COFF in the linux kernel just to support MS-signed linux binaries was a crap idea...no one seems to question that MS is quietly taking over the desktop and redesigning linux systems in window's image...

But I digress, more than a little bit.... ;-/ Just get me thinking about all the crap I have to put up w/because of windows...though better that windows won the desktop war when it did, than Apple, or computers would already be sealed against user tampering... ;-(...

FWIW, Suse is sealing their distro against user upgrading of system components ... like perl... sure you can go put perl in a private dir, but if your system runs on perl (and bash) scripts like mine does, multiple users, including root need to default to the one I use -- never used to be a problem before the binary-boot-signing thing...*sigh*...