I woke up this sleepy Saturday morning and decided to check out what was happening on Twitter. My network on Twitter consists of one friend Dhananjay Nene who twitters regularly (http://twitter.com/dnene) coupled with many others who have done nothing other than twittering "Test" or "Checking this out" and then tuning out completely. Anyway, to come back to the point, I saw this entry by Dhananjay
"Brian Kernighan "Sometimes the old Ways are Best" - http://tinyurl.com/c2ydgc - Precisely the reason why I cant stop using Linux. 10:37 AM Jan 22nd from TwitterFox"
Reading Brian Kernighan's name brought back many happy memories. I think he must be the best writer on programming and I will recommend that anybody who has not read his writings should definitely do so. I hastened to read the link and it turned out a fairly so-so article by BK's standards. I did not find nothing very new in it that I had not already read. He talks about how typical UNIX tools are so effective and often do a much better job than most supposedly advanced toolys such as IDEs. I couldn't help relating to his angst given how I had suffered very recently with trying to achieve a fairly straightforward task in Windows simply because Windows and Windows tools aren't designed neatly (unlike UNIX tools of old).
What I needed to do was the following:
- Write a program P1 that set the permissions on a certain Windows directory (say "d") so that user "U" had full permissions on "d"
- Write another program P2 that would be invoked at a later point of time that would restore the original permissions whatever they might be.
One could assume that P1 would be followed by P2 so the conditions are fairly straightforward. Essentially the scenario was that I would run P1, run some tests and reset the permissions on "d" by invoking P2.
Under Linux this would be so straightforward:
- P1 would consist of one line : getfacl d >oldacls
- P2 would consist of one line : setfacl -f oldacls d
In Windows on the other hand I had the following problems:
- Windows has at least three programs that manage file ACLs, not all of which work on all versions of Windows - cacls, xcacls, icacls
- Except for icacls that is only supported on Vista and later, none of the programs provide a convenient way for storing current ACLs.
- cacls is available on all Windows platforms post-2000 (which was o.k. for me) but not all cacls had a "/S" switch that prints current ACLs
- In settings where I can use "cacls /S" to get the current ACLs I still need to parse the output which looks something like c:\dir1\dir2\currentdir: "a long ACL string". Unfortunately parsing this string and extracting the ACLs for d1 is not at all trivial in Windows, unless of course we were using UNIX tools such as grep or perl or awk.
Unfortunately for me, using any of the UNIX tools was not an option so I had to end up writing over 100 lines of C# code! Can you believe it?
Posts
