Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.misc > #16601 > unrolled thread

Re: How do *nix machos handle M$ problems?

Back to article view | Back to comp.os.linux.misc

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: How do *nix machos handle M$ problems? "Anonymous Remailer (austria)" <mixmaster@remailer.privacy.at> - 2015-12-26 14:54 +0100
    Re: How do *nix machos handle M$ problems? The Natural Philosopher <tnp@invalid.invalid> - 2015-12-26 14:54 +0000
      Re: How do *nix machos handle M$ problems? floyd@apaflo.com (Floyd L. Davidson) - 2015-12-26 07:56 -0900
        Re: How do *nix machos handle M$ problems? The Natural Philosopher <tnp@invalid.invalid> - 2015-12-26 17:29 +0000
        Re: How do *nix machos handle M$ problems? Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2016-01-03 05:27 +0000

#16601 — Re: How do *nix machos handle M$ problems?

Kenny McCormack <gaze...@shell.xmission.com> [KM]:
KM> The funny thing about this is that this is anything but a MS
KM> problem.
KM> I'm no MS apologist, but the cold hard fact is that Windows does
KM> better than Unix on this issue, in at least two ways:

It's not unix itself that has a problem with filenames
containing arbirtrary characters (except / and NUL of course),
it's the shell (and even that is by necessity: certain
(unescaped) characters initiate certain shell actions).

The newer generation of unix users, who have never worked in terminal
mode, have no problem using just about any weird filename. Their
GUI-based file manager and other applications can deal with them just
fine.

So it's not a unix vs. DOS issue. It's a shell vs. DOS issue.

[toc] | [next] | [standalone]

#16605

On 26/12/15 13:54, Anonymous Remailer (austria) wrote:
>
> Kenny McCormack <gaze...@shell.xmission.com> [KM]:
> KM> The funny thing about this is that this is anything but a MS
> KM> problem.
> KM> I'm no MS apologist, but the cold hard fact is that Windows does
> KM> better than Unix on this issue, in at least two ways:
>
> It's not unix itself that has a problem with filenames
> containing arbirtrary characters (except / and NUL of course),
> it's the shell (and even that is by necessity: certain
> (unescaped) characters initiate certain shell actions).
>
> The newer generation of unix users, who have never worked in terminal
> mode, have no problem using just about any weird filename. Their
> GUI-based file manager and other applications can deal with them just
> fine.
>
Its a shame slashes aren't allowed so that 'diary-27/12/15.txt' isn't a 
file..

> So it's not a unix vs. DOS issue. It's a shell vs. DOS issue.
>
Dunno. I couldn't rename a file to:

'Pirates of the Carribean:The Curse of the Black Pearl.mp4'

I think its too long maybe


-- 
the biggest threat to humanity comes from socialism, which has utterly 
diverted our attention away from what really matters to our existential 
survival, to indulging in navel gazing and faux moral investigations 
into what the world ought to be, whilst we fail utterly to deal with 
what it actually is.

[toc] | [prev] | [next] | [standalone]

#16610

The Natural Philosopher <tnp@invalid.invalid> wrote:
>On 26/12/15 13:54, Anonymous Remailer (austria) wrote:
>>
>> Kenny McCormack <gaze...@shell.xmission.com> [KM]:
>> KM> The funny thing about this is that this is anything but a MS
>> KM> problem.
>> KM> I'm no MS apologist, but the cold hard fact is that Windows does
>> KM> better than Unix on this issue, in at least two ways:
>>
>> It's not unix itself that has a problem with filenames
>> containing arbirtrary characters (except / and NUL of course),
>> it's the shell (and even that is by necessity: certain
>> (unescaped) characters initiate certain shell actions).
>>
>> The newer generation of unix users, who have never worked in terminal
>> mode, have no problem using just about any weird filename. Their
>> GUI-based file manager and other applications can deal with them just
>> fine.
>>
>Its a shame slashes aren't allowed so that
>'diary-27/12/15.txt' isn't a file..

Who cares. Use 'diary-27-12-15.txt'.

>> So it's not a unix vs. DOS issue. It's a shell vs. DOS issue.
>>
>Dunno. I couldn't rename a file to:
>
>'Pirates of the Carribean:The Curse of the Black Pearl.mp4'

Why not, looks easy. I literally cut and pasted the above line into a
command line, hit return and then ran "ls -l Pirate*' to see what
was there:

   $>'Pirates of the Carribean:The Curse of the Black Pearl.mp4'
   $ls -l Pirates*mp4
   -rw-r--r-- 1 floyd  users 0 Dec 26 07:52 Pirates of the Carribean:The Curse of the Black Pearl.mp4

>I think its too long maybe

Operator error.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#16611

On 26/12/15 16:56, Floyd L. Davidson wrote:
> The Natural Philosopher <tnp@invalid.invalid> wrote:
>> On 26/12/15 13:54, Anonymous Remailer (austria) wrote:
>>>
>>> Kenny McCormack <gaze...@shell.xmission.com> [KM]:
>>> KM> The funny thing about this is that this is anything but a MS
>>> KM> problem.
>>> KM> I'm no MS apologist, but the cold hard fact is that Windows does
>>> KM> better than Unix on this issue, in at least two ways:
>>>
>>> It's not unix itself that has a problem with filenames
>>> containing arbirtrary characters (except / and NUL of course),
>>> it's the shell (and even that is by necessity: certain
>>> (unescaped) characters initiate certain shell actions).
>>>
>>> The newer generation of unix users, who have never worked in terminal
>>> mode, have no problem using just about any weird filename. Their
>>> GUI-based file manager and other applications can deal with them just
>>> fine.
>>>
>> Its a shame slashes aren't allowed so that
>> 'diary-27/12/15.txt' isn't a file..
>
> Who cares. Use 'diary-27-12-15.txt'.
>
>>> So it's not a unix vs. DOS issue. It's a shell vs. DOS issue.
>>>
>> Dunno. I couldn't rename a file to:
>>
>> 'Pirates of the Carribean:The Curse of the Black Pearl.mp4'
>
> Why not, looks easy. I literally cut and pasted the above line into a
> command line, hit return and then ran "ls -l Pirate*' to see what
> was there:
>
>     $>'Pirates of the Carribean:The Curse of the Black Pearl.mp4'
>     $ls -l Pirates*mp4
>     -rw-r--r-- 1 floyd  users 0 Dec 26 07:52 Pirates of the Carribean:The Curse of the Black Pearl.mp4
>
>> I think its too long maybe
>
> Operator error.
>
Mmm. no it was an editor program that had a restricted file name length. 
I renamed it OK using Caja


-- 
the biggest threat to humanity comes from socialism, which has utterly 
diverted our attention away from what really matters to our existential 
survival, to indulging in navel gazing and faux moral investigations 
into what the world ought to be, whilst we fail utterly to deal with 
what it actually is.

[toc] | [prev] | [next] | [standalone]

#16656

On 2015-12-26, Floyd L. Davidson <floyd@apaflo.com> wrote:

> The Natural Philosopher <tnp@invalid.invalid> wrote:
>
>> Its a shame slashes aren't allowed so that
>> 'diary-27/12/15.txt' isn't a file..
>
> Who cares. Use 'diary-27-12-15.txt'.

Or "diary.27-12-15.txt" - there's nothing sacred about
periods in Unix file names.

I'd prefer "diary.15-12-27.txt" instead; expressing dates
as year-month-day means that if you have several such files
for different dates, their names will sort into chronological
order.  See https://en.wikipedia.org/wiki/ISO_8601

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.misc

csiph-web