[pvrusb2] Permission denied writing to cur_val

[Mike Isely]

On Tue, 21 Oct 2008, Michael Krufky wrote:

> 
> An explanation for why sudo does not work:
> 
> The sysfs interface creates a filesystem that can only be touched by
> root.  The "sudo" command elevates privileges for the "echo" command,
> but the redirection " > " is still being handled by the shell (bash)
> that the user is actually logged in to.  If you do "sudo su" , that
> will start a new shell AS user root, and then redirection will work.

D'Oh!!

A couple bits to add:

"sudo -s" should just fork a root shell and leave you with a root 
prompt.  This is probably a little more efficient than sudo su which 
probably forks 2 shells.  Once inside such a shell you can leave it 
return back to the parent shell just by exiting it in the usual way.  I 
don't normally use sudo, but the last time I did (under OS X, of all 
places), that worked.

Yes, I see it's obvious now that ">" went to the outer shell rather than 
inside the sudo.  So entering a new shell with "sudo -s" should solve 
it.  Alternatively, this might work too:

	sudo "echo s-video >cur_val"

Assuming that sudo actually uses a separate temporary shell to run echo 
(I think it does), then the quoting forces the ">" to be used by that 
temporary shell rather than your outer shell.

While on this topic, here are a few other things that are worth knowing:

If you try to feed an "illegal" keyword to one of these files, for 
example trying to set the input to "foobar", the write will deliberately 
fail and you'll get an error from attempt.  It won't be EPERM, probably 
either EINVAL or ENOTTY depending on the situation.  The driver does 
this.

But if the redirected output write fails, sometimes the shell can 
behave, well, "strangely".  I've seen cases when using echo where the 
shell actually holds onto the text you tried to write and will write it 
out again on the next echo attempt - which can produce more errors since 
what actually gets written to the file is not what you had attempted.  
It's easy to demonstrate this:

	echo "foo" >/sys/class/pvrusb2/*/ctl_input/cur_val
	echo "bar" >/tmp/test.txt
	cat /tmp/test.txt

and you might see it cat "foobar"...  Whether or not this happens likely 
depends on the exact shell being used and probably whether or not "echo" 
is a builtin command.  I've seen it happen when using bash.  This entire 
behavior has little to do with the driver and everything to do with the 
shell environment.  Just a heads up...

  -Mike


-- 

Mike Isely
isely @ pobox (dot) com
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8