in reply to Semicolon delimited to Comma delimited

ww lists your technical options nicely; either use splitand join and prepare to reinvent the wheel for handling edge cases, or look into mucking about with Perl's internal handlers.

That said, this is the first time I've ever heard of using semi-colons instead of commas in a Comma-Separated Values (CSV) file (.csv).

I have, of course, heard of using tabs in a Tab-Separated Values (TSV) file (.tsv).

The pedantic engineer in me is curious why it isn't called an SDV SSV or SCDV SCSV file (Semi-Colon-Delimited-Separated Values File), but I suppose the answer is that when people start tossing terms around, the original context is frequently lost, and whoever made the decision to change the standard either was ignorant of what CSV actually meant, or worked at Microsoft.

Replies are listed 'Best First'.
Re^2: Semicolon delimited to Comma delimited
by swatzz (Novice) on Apr 23, 2015 at 13:56 UTC

    Yea well that's the European format of *.csv files. My script was to extract data from a *.csv file and write into Excel(with multiple data in multiple sheets). It worked fine in my system but did not run with my counterpart in India. And then i figured out that the European system uses the semi-colon instead of comma in *.csv files :(

      I empathize; despite what could have been a small rantlette above, I get it.

      I am curious, though -- there are many reasons why some people avoid CPAN Modules. If you don't mind my asking, what's yours?

      I, for example, would prefer to use them -- but I had an astoundingly lengthy run (near twenty-ish years) of bad luck where either the module didn't exist, was broken, could not be installed, or was adminstratively prohibited.

      As a result, I've built up a sizeable collection of home-spun Perl Modules which do most of the work I need.

      I've watched the CPAN community evolve very nicely -- potentially the single most respectable collection of collaborate works I've ever seen -- and I sit here and plod along with stuff which I know is either substandard or not as robust as it could be. I know how to use it and it does what I need, and so now it would take more time to refactor into the use of CPAN Modules.

      As much as I'd like to, getting heavily into CPAN Modules is not in the cards for me. There's not much time left in my career, and I'm mostly just maintaining stuff written by others long gone while it waits to be replaced by what are perceived to be more modern tools.

      LOL -- I've become my own thirty-ton gorilla.

      So I'm curious -- what's the cause of your reticence to use external Modules?

        Haha! Well since you ask, i have nothing against CPAN modules. I have used many in the past for developing my work products. The problem arises mainly because of Perl versions. Some modules run on some versions and not all end users have the version i use for developing the tool. Now this is where a conflict is already building up. Then comes the problem of people mostly preferring to use what comes bundled in Active Perl. Asking them to additionally use a CPAN package is mostly ignored!! Even if people are ready to go the extra way and download the CPAN package that needs to be there in addition to default Perl packages, they particularly dont pay attention to the versions!

        So in all its a bummer, especially if my tool is to be used by some user sitting in another continent! I end up more time sorting out the Perl/Perl libraries issues. So there you go, that's my cause for reticense!!