OK, so here goes...

Under Unix, you can type a shell command and end it with "&" (IIRC), and 
it runs in the background. Is there any way of doing this under Windows?

Also, Unix as "sudo". Does Windows have anything similar?

(I just discovered that on Vista, you can't install Haskell packages 
because the installer doesn't have permission to write the files. But 
how the hell do you *give* it permission??)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On Sun, 10 May 2009 22:04:09 +0200, Orchid XP v8 <voi### [at] devnull> wrote:
>
> Under Unix, you can type a shell command and end it with "&" (IIRC), and  
> it runs in the background. Is there any way of doing this under Windows?

As far as I know there is no way to run several concurrent processes in a  
single command window, but you can use the "start" command to give the new  
process its own window.


> Also, Unix as "sudo". Does Windows have anything similar?

Yes, "runas".


> (I just discovered that on Vista, you can't install Haskell packages  
> because the installer doesn't have permission to write the files. But  
> how the hell do you *give* it permission??)

Right-click the installer and select "Run as administrator".


-- 
FE

Post a reply to this message

>> Under Unix, you can type a shell command and end it with "&" (IIRC), 
>> and it runs in the background. Is there any way of doing this under 
>> Windows?
> 
> As far as I know there is no way to run several concurrent processes in 
> a single command window, but you can use the "start" command to give the 
> new process its own window.

This is what I was looking for. Thanks.

>> Also, Unix as "sudo". Does Windows have anything similar?
> 
> Yes, "runas".

OK, I'll give that a try.

>> (I just discovered that on Vista, you can't install Haskell packages 
>> because the installer doesn't have permission to write the files. But 
>> how the hell do you *give* it permission??)
> 
> Right-click the installer and select "Run as administrator".

Hmm. I'd have to compile the installer first. (Usually you just run the 
installation program through the Haskell interpretter...)

Presumably I can use runas to give myself a command prompt with admin 
access. (?)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> This is what I was looking for. Thanks.

Note that this is also the command equivalent for "nice".

> Hmm. I'd have to compile the installer first. (Usually you just run the 
> installation program through the Haskell interpretter...)

Start the haskell interpreter that way. Note that you're really running as 
administrator, so files created will be owned by administrator, etc. Sudo 
only changes part of your identity.

> Presumably I can use runas to give myself a command prompt with admin 
> access. (?)

Or right-click on the command prompt icon and pick "run as administrator".

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

>> This is what I was looking for. Thanks.
> 
> Note that this is also the command equivalent for "nice".

What does "nice" do?

>> Hmm. I'd have to compile the installer first. (Usually you just run 
>> the installation program through the Haskell interpretter...)
> 
> Start the haskell interpreter that way. Note that you're really running 
> as administrator, so files created will be owned by administrator, etc. 
> Sudo only changes part of your identity.

I don't think file ownership will be a problem. The permissions on the 
folder are set correctly, so I think it'll work.

(I wonder how you get it to do the thing where it *asks* for permission 
to do stuff?)

Interestingly, the other day I tried to unzip a file into Program Files 
and 7zip couldn't do it. However, Windows Explorer could. (It asked for 
permission.) Interesting, eh? :-.

>> Presumably I can use runas to give myself a command prompt with admin 
>> access. (?)
> 
> Or right-click on the command prompt icon and pick "run as administrator".

This works on XP, but under Vista I couldn't see an option for that...

Post a reply to this message

Invisible wrote:
>>> This is what I was looking for. Thanks.
>>
>> Note that this is also the command equivalent for "nice".
> 
> What does "nice" do?

	Allows you to run processes at a lower (or higher) priority.


-- 
DO NOT REMOVE THIS TAG (UNDER PENALTY OF LAW)


                    /\  /\               /\  /
                   /  \/  \ u e e n     /  \/  a w a z
                       >>>>>>mue### [at] nawazorg<<<<<<
                                   anl

Post a reply to this message

>>> Note that this is also the command equivalent for "nice".
>> What does "nice" do?
> 
> 	Allows you to run processes at a lower (or higher) priority.

Ah, I see. (Why the heck is it called "nice" then?)

I hadn't noticed the priority options to the "start" command...

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> Ah, I see. (Why the heck is it called "nice" then?)

  Because when you write "nice program" in unix, it will start the program
at a lower priority, so that it will act nicer (ie. consume less resources).

  This comes from the principle that unix is a multiuser system, and one
user hogging all the CPU is not nice, so it was always recommended to
start long-running CPU-heavy programs with "nice".

-- 
                                                          - Warp

Post a reply to this message

Invisible wrote:
> I don't think file ownership will be a problem. The permissions on the 
> folder are set correctly, so I think it'll work.

Yeah.  NTFS has a better permissions model than UNIX does, so it's easier to 
make sure files in a directory end up properly permissioned.

> (I wonder how you get it to do the thing where it *asks* for permission 
> to do stuff?)

There's a flag in the header of the executable. Alternately, ...

> Interestingly, the other day I tried to unzip a file into Program Files 
> and 7zip couldn't do it. However, Windows Explorer could. (It asked for 
> permission.) Interesting, eh? :-.

... you try, you fail with a "permission denied" message, and you put up a 
prompt saying "would you like to try again as administrator?"

>> Or right-click on the command prompt icon and pick "run as 
>> administrator".
> 
> This works on XP, but under Vista I couldn't see an option for that...

Open the start menu (with a left click), navigate until you see the command 
prompt icon on the menu, and right click it. The second option should be 
"run as administrator". It's the one with the security shield icon next to it.

Alternately, start a command prompt and see if it already says 
"administrator" in the title bar, in which case you've already configured 
your machine to bypass all the security stuff. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Invisible wrote:
>>>> Note that this is also the command equivalent for "nice".
>>> What does "nice" do?
>> 
>> Allows you to run processes at a lower (or higher) priority.
> 
> Ah, I see. (Why the heck is it called "nice" then?)

A nice process shares more resources with the rest.

Post a reply to this message

Invisible wrote:
> Ah, I see. (Why the heck is it called "nice" then?)

Note that "nice" is being used as a verb, as in "make this process nice."

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> NTFS has a better permissions model than UNIX does

  I like how you are comparing a file system to an operating system, like
they were the same type of thing, comparable to each other.

  (One thing I really fail to understand about NTFS: Since NTFS has so
many fancy features, why doesn't WinXP support them? And by support I mean
it doesn't offer any kind of user interface to handle them, not even for
power users, who could benefit from it.
  Is Vista any better in this regard? Knowing Microsoft, I wouldn't be
surprised if it wasn't.)

-- 
                                                          - Warp

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> Invisible wrote:
> > Ah, I see. (Why the heck is it called "nice" then?)

> Note that "nice" is being used as a verb, as in "make this process nice."

  Compare to "renice", which changes the priority of an already running
process.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> NTFS has a better permissions model than UNIX does
> 
>   I like how you are comparing a file system to an operating system, like
> they were the same type of thing, comparable to each other.

If UNIX permissions systems suck, you're not going to be able to write a 
decent file system permissions mechanism, unless you go outside the realm of 
UNIX.  (E.g., SQL has a sophisticated permissions system implemented under 
UNIX, but you can't access it via the normal UNIX mechanisms. The same holds 
for GFS.)

Just like if your file system sucks, it doesn't matter how good your 
permission system is in the OS, it's not going to work on the files. (e.g., 
FAT under NT sucks permissions-wise.)

NTFS only runs under NT/XP/Vista/etc.  NTFS under UNIX has a suckful 
permission system, indeed even worse than ext under UNIX. But I knew if I 
said XP has a better permission system, someone would gripe about FAT under 
XP being worse than UNIX, so I phrased it the way I did very carefully. The 
thing holding back good permissions for a file system on Windows is the file 
system (FAT sucks, NTFS is good). The thing holding back good permissions 
for a file system on UNIX is the kernel (all FS's suck equally, because the 
infrastructure needed just isn't in the kernel). Hence the comparison.

Unless you have an example of a UNIX file system whose permissions are 
comparable to NTFS's? If you do, let me know, because that would be awesome.

>   (One thing I really fail to understand about NTFS: Since NTFS has so
> many fancy features, why doesn't WinXP support them? And by support I mean
> it doesn't offer any kind of user interface to handle them, not even for
> power users, who could benefit from it.

Like what is lacking?  A lot of the more sophisticated features don't make 
sense to use without the backing of particular software. For example, it 
doesn't make sense to provide a detailed user interface for offlined files 
if you don't have any backup software installed that creates offlined files.

The only NTFS feature I'm aware of that doesn't come with some GUI built 
into explorer somewhere to handle it is hard and soft links.

>   Is Vista any better in this regard? Knowing Microsoft, I wouldn't be
> surprised if it wasn't.)

It depends what features you're talking about, but generally, yes.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

On Mon, 11 May 2009 17:58:49 +0200, Darren New <dne### [at] sanrrcom> wrote:
>> (I wonder how you get it to do the thing where it *asks* for permission  
>> to do stuff?)
>
> There's a flag in the header of the executable.

Is there? I thought this was configured in the manifest.



-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:
> On Mon, 11 May 2009 17:58:49 +0200, Darren New <dne### [at] sanrrcom> wrote:
>>> (I wonder how you get it to do the thing where it *asks* for 
>>> permission to do stuff?)
>>
>> There's a flag in the header of the executable.
> 
> Is there? I thought this was configured in the manifest.

I was sloppy. I should have said "it's a flag in the metadata in the 
executable".  Better? :-)

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Darren New wrote:
> Unless you have an example of a UNIX file system whose permissions are
> comparable to NTFS's? If you do, let me know, because that would be
> awesome.

There ARE ACL systems for Unix.

Post a reply to this message

Nicolas Alvarez wrote:
> Darren New wrote:
>> Unless you have an example of a UNIX file system whose permissions are
>> comparable to NTFS's? If you do, let me know, because that would be
>> awesome.
> 
> There ARE ACL systems for Unix.

Yes, but still based on the UID, on root having all access, and so on. And 
as far as I can tell, no per-file encryption, no inherited permissions.

For example, when I can unplug a USB drive off one Unix system and plug it 
into a different one and Fred (uid 1002) can't get to Jane's files (also uid 
1002) on the USB drive, I'll be pleasantly surprised. Is there anything 
already in Linux or whatever to make that work?

Does the Linux equivalent of "active directory" (which was Kerberos last I 
looked) interact with the local file system well?

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Darren New wrote:

> For example, when I can unplug a USB drive off one Unix system and plug 
> it into a different one and Fred (uid 1002) can't get to Jane's files 
> (also uid 1002) on the USB drive, I'll be pleasantly surprised. Is there 
> anything already in Linux or whatever to make that work?

Windows does this by assigning to every PC and every domain a large 
random number which is hopefully "unique". Every user account created on 
a specific PC has that PC's number as part of the account number. 
Similarly, every domain user account has the domain number as part of 
the account number.

If, by some freak of nature, two machines had the same ID, you could 
indeed to weird stuff like what you're suggesting. It's just rather 
unlikely. (Cloning a harddrive image and forgetting to randomise the ID 
afterwards is about the only way...)

> Does the Linux equivalent of "active directory" (which was Kerberos last 
> I looked) interact with the local file system well?

Last I checked, Active Directory uses the (pre-existing) Kerberos 
network protocol for authentication.

As I understand it, Kerberos defines the wire protocol for how an 
arbitrary client connects to an arbitrary server and authenticates 
itself. What kind of security model you build using this is completely 
up to you.

In the case of MS, they built the domain model. [Or, more exactly, took 
their existing domain model and replaced the horribly broken LANMAN 
subsystem with Kerberos.]

Kerberos says nothing about what happens on the local machine. The MS 
domain security model does.

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> Kerberos says nothing about what happens on the local machine. The MS 
> domain security model does.

Right. And my basic question there was whether the UNIX stuff underlying the 
kerberos can distinguish uid 1002 on one machine from uid 1002 on another 
machine.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

On Tue, 12 May 2009 13:54:10 -0700, Darren New wrote:

> Yes, but still based on the UID, on root having all access, and so on.
> And as far as I can tell, no per-file encryption, no inherited
> permissions.

Novell Storage System (NSS) on Linux isn't based on this at all.  ACLs 
are completely eDirectory-dependent and root (while they might be able to 
see stuff in the filesystem) doesn't automatically have all rights to the 
files.

:-)

Jim

Post a reply to this message

Darren New wrote:
> Orchid XP v8 wrote:
>> Kerberos says nothing about what happens on the local machine. The MS
>> domain security model does.
> 
> Right. And my basic question there was whether the UNIX stuff underlying
> the kerberos can distinguish uid 1002 on one machine from uid 1002 on
> another machine.

In the same way a Windows domain has globally-unique UIDs shared between
systems, I guess you could network-mount or in some other way
keep /etc/passwd synced across computers. Then a username will mean the
same UID in any machine.

Post a reply to this message

Jim Henderson wrote:
> Novell Storage System (NSS) on Linux isn't based on this at all. 

How does NSS know who is trying to access the files?  Do you have to use a 
non-Linux login to connect to the storage system or something?

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

Nicolas Alvarez wrote:
> In the same way a Windows domain has globally-unique UIDs shared between
> systems, I guess you could network-mount or in some other way
> keep /etc/passwd synced across computers. 

Only if they're all network connected from the start.  I can't take two 
already-set-up UNIX machines and connect them both to the same NFS drives 
and not expect problems, for example.

Windows manages to make this work even without a domain or network 
connectivity.  Sure, you can get around it with work, but the default isn't 
to confuse two accounts as one just because they come from different machines.

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message

On Tue, 12 May 2009 20:10:29 -0700, Darren New wrote:

> Jim Henderson wrote:
>> Novell Storage System (NSS) on Linux isn't based on this at all.
> 
> How does NSS know who is trying to access the files?  Do you have to use
> a non-Linux login to connect to the storage system or something?

Yes, you login through eDirectory.

The eDirectory user can be a LUM (Linux User Management) enabled user, 
which uses the LDAP integration to authenticate local users to the 
directory, but yeah, it can be configured to be entirely independent of 
the OS' use of UID.

Jim

Post a reply to this message