public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: Andrey Repin <anrdaemon@yandex.ru>
To: "D. Boland" <daniel@boland.nl>, cygwin@cygwin.com
Subject: Re: vi stealing SYSTEM-owned permissions and ownership
Date: Sun, 03 Nov 2013 22:05:00 -0000	[thread overview]
Message-ID: <2610586421.20131104015911@mtu-net.ru> (raw)
In-Reply-To: <527698EA.16C8F45C@boland.nl>

Greetings, D. Boland!

>> Your main problem is that you are trying to break into native Windows
>> ACL system with Cygwin tools. And not only that, you also trying to
>> wrest native ACLs into POSIX permissions, and expect native applications to
>> work fine afterward.
>> Which can be done theoretically, but in reality is a real big headache to
>> maintain.

> You are speaking of Cygwin as if it's some kind of quick hack.

It is NOT a "quick hack". But to work across different paradigm boundaries,
you have to know, what exactly it means and how it works.

> This is not the case. Most of the tools are of the GNU software collection,
> which is high quality software. ACL is also available on other Linux
> flavours, and they don't have to "wrest" it into POSIX.

I'm NOT talking about tools provided. I tell you about inherent difference
between POSIX and Windows ACL's, short version and consequences of which I've
explained already, and you can find some more technical details in Cygwin
documentation. 

> Also, one could say that ACL is a superset of the POSIX model.

No, unfortunately, you can not. As I said, there's inherent differences.

> It uses POSIX's idea of users, groups and others, but then offers the
> posibility to add more users and groups for more elaborate schemes. The
> headache starts when one actually starts using these extra posibilities.

POSIX ACL do not use selective inheritance model, as I'm aware.

>> If you truly want to show your students their Windows systems from the command
>> line, I suggest you learn Windows command line.
>> If not very robust, it is nonetheless rich, and allow for many operations
>> normally performed from GUI, and some operations, that can not be done from
>> GUI, either without much complication or at all.
>> In the case mentioned below, the "net" tool should come in handy. As well
>> as "sc" tool.

> I could just give my students an iMac, but these are not used in IT production
> infrastructures. Windows (business/government) and Linux/Unix (ISP's) are.

You make it sound like Macs are something from a parallel universe.
Same *NIX, just more thoroughly put together. For the record: I've had a
MacBook for near a year. Wrested it all to my needs. No problem whatsoever.

> The Windows command line is frustrating to work on. For instance, their
> implementation of autocompleting with the tab-key sucks.

I'll give you a hint: http://farmanager.com/index.php?l=en

> In stead of really simplifying and improving on DOS, MS comes up with more
> weird tools like PowerShell.
> Now you have to be a programmer to use the command-line.

No need to "use command line". This is where you make a mistake. You use
command-line tools to perform specific tasks. That's it.
But if you inclined to "use command line", check out http://jpsoft.com/all-downloads/downloads.html

>> Also, forcing someone to use vi over more sane editors is a torture which no
>> one deserve.
>> 

> Haha, yes. But if my students have to administer remote production-machines,
> most of the time they have no other option. I want them to succeed where
> others fail. 

I can't imagine a situation, where I only have one way to edit the file.
Even on my web hosting, I have a choice between vi, mcedit, ed and ee.


--
WBR,
Andrey Repin (anrdaemon@yandex.ru) 04.11.2013, <01:39>

Sorry for my terrible english...


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

  reply	other threads:[~2013-11-03 22:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-02 12:55 D. Boland
2013-11-02 13:36 ` Brian S. Wilson
2013-11-02 18:42   ` Andrey Repin
2013-11-02 21:58   ` D. Boland
2013-11-02 22:35     ` Andrey Repin
2013-11-03 18:47       ` D. Boland
2013-11-03 22:05         ` Andrey Repin [this message]
2013-11-04 11:23         ` Brian S. Wilson
2013-11-04 14:54           ` Lavrentiev, Anton (NIH/NLM/NCBI) [C]
2013-11-04 17:05             ` Larry Hall (Cygwin)
2013-11-05  5:54 ` D. Boland
2013-11-05 17:38   ` Achim Gratz
2013-11-08 14:25     ` D. Boland
2013-11-08 15:59       ` Lavrentiev, Anton (NIH/NLM/NCBI) [C]
2013-11-08 20:20       ` Andrey Repin
2013-11-27 18:11   ` D. Boland

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2610586421.20131104015911@mtu-net.ru \
    --to=anrdaemon@yandex.ru \
    --cc=cygwin@cygwin.com \
    --cc=daniel@boland.nl \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).