If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Rate Thread | Display Modes |
#436
|
|||
|
|||
Bad characters in filenames (Was: With DaaS Windows Coming, Say Goodbye To Your PC As You Know It)
In comp.os.linux.misc, nospam wrote:
Kenny McCormack wrote: This (that all other characters are allowed) is a misfeature, but it is the way things are. actually, there should be *no* restrictions at all on which characters can be used in a file name. users should be able to name their files anything they want. unfortunately, we're stuck with a lot of legacy code, so that's not likely to change any time soon, if ever. I think a very good argument could be made for being *very* selective about which characters below ASCII 32 ("SPACE") are acceptable in filenames. Not many users really want or need to use terminal escape code sequences in filenames, nor new lines or backspaces. Elijah ------ but space and up are fair game |
Ads |
#437
|
|||
|
|||
Bad characters in filenames (Was: With DaaS Windows Coming, Say Goodbye To Your PC As You Know It)
In article , Eli the Bearded
wrote: This (that all other characters are allowed) is a misfeature, but it is the way things are. actually, there should be *no* restrictions at all on which characters can be used in a file name. users should be able to name their files anything they want. unfortunately, we're stuck with a lot of legacy code, so that's not likely to change any time soon, if ever. I think a very good argument could be made for being *very* selective about which characters below ASCII 32 ("SPACE") are acceptable in filenames. Not many users really want or need to use terminal escape code sequences in filenames, nor new lines or backspaces. popularity or lack thereof is not a good argument and i wasn't referring to control characters in particular. the only reason it's restricted is legacy code and interoperability with windows, which has the most restricted namespace. |
#438
|
|||
|
|||
[OT] Apple registered developers
Chris writes:
On 08/08/2018 14:00, Ivan Shmakov wrote: nospam writes: [...] anyone can anything and release it in the wild but don't be surprised if very few people bother running it without knowing something about who wrote it or choose a more reputable developer. The authors of WRF (below) look reputable enough. Since you seem to be experienced with Apple products, could you please check if they're registered? Also for CORSIKA, if that's not much trouble. Neither requires registration as the software is distributed as source code which requires compiling on the target system. In theory, as they're FORTRAN and/or C code designed for UNIX systems there's a good chance they will work on a Mac. Well, I'd hope so. However, I do not expect it to run any better on OS X than on GNU/Linux; or do I? As such, it seems reasonable to go with the cheaper solution. I can't tell for sure as the authors of both tools require you to register to download the code. Unfortunately, it's somewhat a widespread practice in scientific software development. However, in the case of WRF specifically, I suppose you can get the source from [1] instead. [1] http://github.com/NCAR/WRFV3 -- FSF associate member #7257 np. Empire of the Clouds -- Iron Maiden |
#439
|
|||
|
|||
Unless they've changed it with the move to OSX... (Was:With DaaS Windows Coming, Say Goodbye To Your PC As You Know It)
The Natural Philosopher wrote:
On 08/08/18 13:18, nospam wrote: In article , Chris wrote: Anyway the point is that a macinstosh data 'file' be it a single entity with two forks internal to HFS or two files as mapped onto any other file system is INCOMPATIBLE with any other opearting system's understanding of a 'file'. I am not concerned with its ultimate representation, just as an example of Apples unconcerned indiffenece to interoperability with others. What the hell are you talking about?! Copying files between macOS, windows and linux is just fine regardless of the source and destination. A pdf or jpeg file is always a pdf or jpeg. yep. there are no issues. https://blog.jay2k1.com/2010/02/03/w...om-smb-shares/ So, you are lying. There are SERIOUS issuess. Hardly. This an edge case where there's a mix of SMB and AFP shares on a network. AND it ONLY affects old style font files. Everyone can relax. The macOS concept of a 'file' is still the same as everyone else. I'm very relieved as otherwise I must have been hallucinating the last 10 years. |
#440
|
|||
|
|||
With DaaS Windows Coming, Say Goodbye To Your PC As You Know It
On 2018-08-08, nospam wrote:
The Apple terminology is apparently data fork and device fork, resource fork, not device fork. that was 20 years ago, *before* mac os x. also, not all files had a resource fork back then. thanks. -- ت |
Thread Tools | |
Display Modes | Rate This Thread |
|
|