john e malmberg ho0ebgqslnet craig berry wrote 111207 demerphq wrote nov 12 2007 1158 pm craig berry wrote filespec routines something compromise need abstraction need right thing local filename syntax dont completely insulate know filename parts split combined parts works differently different platforms thats another topic another time think given troubles caused issue filespec works systems volumes shouldnt necessary programmer know intricate rules system handles file specifications logic encapsulated module like filespec one needs follow instructions module result correct specification however lot learned lot changed since filespec originally written filespec became date vms vms 72 vms 83 believe long term either need rewrite filespec lot intelligence likely better get together design replacement job often see nix people writing code totally ignores volumes resulting code doesnt work win32 general assumption rewrite code volume aware win32 also work vms doesnt id say design flaw needs addressed time appears least functionality fs leads types issues easy people think unix use limited subset fs catdir catfile doesnt port good feature package whose intention facilitate portability started look win32 issues suspect nonunix platforms also issues macs use unix gui different file syntax also dislike people tendency use filespecunix create uris understand john saying post fact uris unix file specs thing happen similar contexts worth discussing differences imo bottom line different beasts using tools one create causes conceptual practical issues could avoided uri unix spec exactly thing best thing vms case give unix spec results interpreting uri really vms wants think needs happen win32 vms people perl design replacement fs issues totally resolved look nix user would use code essentially using unix file system semantics starting point bad call simplest lot thus least likely applicable contexts wheras using complex apparently vms also win32 starting point least likely leave anything picture id happy best carve minimal spare time work project think potential benefit community would considerable vmsperl gurus feel endeavour worthy goals good observations folks built filespec years slouches think youre proposing harder looks harder pick apart reassemble file specs portably ought language im aware even tries count 510 issues vms observed past years would surprised could find similar features nonunix systems case 1 general expected rule routines c library return filenames vms default return vms file specification feature setting change default returning file specification unix format allows building running unix programs vms sometimes even making edit program standard c library routines optional parameter indicates format return program vms aware isolate self feature setting changing behavior filespecvms needs made aware feature setting behave consistently may new routine names needed additional parameters needed backwards compatibility must maintained done existing core dual lived modules may need updated either work modes core modules dual lived usually result removing vms specific code case 2 routines take one filenames input return filename general rule vms format specification input vms format specification output correspondingly unix format file specification input unix format specification output perl currently filespec appears library following rule continually finding new module added core existing code would work filespec follow rule cause 12 problems finding filespec 12 problems finding handling vms ods5 character set problem also programs dual lived modules expect existing filespec behavior additionally though much existing behavior work ods5 file system cases incorrect vms older ods2 file system even though existing perl programs dependent behavior vms c library feature efs_charset indicates using new ods5 syntax instead older ods2 plan make filespecvms aware setting change behavior needed handle ods5 vms unix file specifications expected update needed core dual lived modules work either behavior routine takes multiple filenames input native vms unix something needs break tie output syntax case 1 feature setting indicates way general c library routines accept filename vms accept either vms format one unix one filespecvms routines filespecunix routines work vms given unix input conversion absolute paths work currently uses getcwd returning vms format file specification seems need generic routines convert unix native filenames long shortened form native filename also need features indicate host handle unix format file specifications addition native format think though first step might interesting search core perl modules see os specific checks used summarize platforms c library support unix format paths platforms defined method converting unix native file specifications john ho0ebgqslnet personal opinion thu 07 aug 2008 183350 0600 replace fs something truely portable