RM/RMIR v2.01 now available (overflow, ExtInstall, more ...)

[Barf]

On the issue of path names containing spaces (not really restricted to Linux):

I wrote a new wrapper:

Code: Select all

#!/bin/sh

JAVA_HOME=/opt/\ a\ truly\ silly\ path\ /jre1.6.0_29
JAVA=${JAVA_HOME}/bin/java

RMHOME=/local/\ an\ even\ sillier\ path\ 

PROPSFILE=${HOME}/.\ if\ this\ is\ not\ sick,\ nothing\ is\ 
LIBRARIES=/local/\ truly\ braindamaged\ library\ path\ \ 

if [ `basename $0` = "rmir" ] ; then
    RMIR=-ir
elif [ `basename $0` = "rmaster" ] ; then
    RMIR=-rm
else
    RMIR=
fi

if [ $# -eq 1 ] ; then
    if [ `dirname $1` = "." ] ; then
	file=`pwd`/$1
    else
	file=$1
    fi

    exec "${JAVA}" -Djava.library.path="${LIBRARIES}" -jar "${RMHOME}/RemoteMaster.jar" -h "${RMHOME}" -properties "${PROPSFILE}" ${RMIR} "$file"
fi

exec "${JAVA}" -Djava.library.path="${LIBRARIES}" -jar "${RMHOME}/RemoteMaster.jar" -h "${RMHOME}" -properties "${PROPSFILE}" ${RMIR}

Note the use of truly silly pathnames, not only with embedded spaces, but also with leading and trailing spaces. And everything worked! (Actually with the exception of the library path, since that has not been implemented in RemoteMaster (Greg, Graham: ask me for a patch if desired).)

However, the wrappers rmaster.sh and rmir.sh will break on pathnames with spaces.

@JD4x4: You do not need any wrapper at all, just something like

Code: Select all

java -jar "/pathname possibly with spaces/RemoteMaster.jar" -h "/pathname possibly with spaces"

should do the trick.

Next issue:

It also expects to have full read/write/execute permission to those files and directories.

IFAIK, the only thing written under normal operation is the property file RemoteMaster.properties. This can be changed with the (undocumented?) -properties option (see my script above). Also in the Windows world it is considered a bad habit of writing to the installation directory. Putting the property file in, e.g. the users home direcory (Linux/Mac?), AppData-something (Windows) may be everything needed to make the program clean in this sense.

[vickyg2003]

My suggestion

can I suggest changing the order in autodetection since more people are using the serial/usb interface and the parallel seems to have issues?

still appears to be sensible, as it will at least sometimes help some people.

Apparently this was done in 2.02 beta and it broke autodetection completely. A little history on this. Autodection used to crash RMIR when I was using an LPT cable and the remote was not found. Since I have one of those finicky cables that makes me do all the battery tricks to get the remote to detect, this was a huge problem for me. I worked with Graham, and he fixed the crashing, and also ordered the autodetect so that it worked with my LPT JP1, my USB JP1, my Serial JP1.x and my JP1.2/3. After Greg changed the order for 2.02 beta only my serial JP1.x and my JP1.2/3 can be autodetected. Everytime I try to open autodetect, it stops at the serial interface. Do you think its detecting my widget? Whatever the reason, the new setup doesn't autodetect under windows at all for me.

[vickyg2003]

Next issue:

It also expects to have full read/write/execute permission to those files and directories.

IFAIK, the only thing written under normal operation is the property file RemoteMaster.properties. This can be changed with the (undocumented?) -properties option (see my script above). Also in the Windows world it is considered a bad habit of writing to the installation directory. Putting the property file in, e.g. the users home direcory (Linux/Mac?), AppData-something (Windows) may be everything needed to make the program clean in this sense.

Windows Vista and Window 7 hates it if an app writes information in the "Program Files" sub folders from an app. "Program Files" is a restricted directory. Any changes to the program files directory after installation go in a hidden data stores area. A normal user can't find them, you even a reinstall can't fix them.

I normally don't recommend installing JP1 programs in the Program Files Folder simply because many of the older programs are not Windows 7 compliant and tend to store information in their home folder.

[JD4x4]

(snip)
@JD4x4: You do not need any wrapper at all, just something like

Code: Select all

java -jar "/pathname possibly with spaces/RemoteMaster.jar" -h "/pathname possibly with spaces"

should do the trick.

Using that in either terminal or the Run Application dialog does in fact launch either prog, however for some reason neither prog will exit (!?). I have to run System Monitor, where I find it's 'Waiting Channel' is 'futex_wait_queue_me' .. whatever that is, and I have to end the process from there. (Ubuntu 11.04 AMD 64bit)

Your message got me thinking about quotes in the shell command line however, and in my rush to get running I must not have tried one combination- the one that works!

Here is how I changed the last lines in each .sh file, and they now work with my path that has spaces:

rmir.sh -
gksudo "java -Djava.library.path='$path' -jar '$path/RemoteMaster.jar' -h '$path' -ir"

rmaster.sh-
gksudo "java -Djava.library.path='$path' -jar '$path/RemoteMaster.jar' -h '$path' -rm"

Note the addition of single quotes in each, and in the case of rmaster.sh the addition of -rm, which was missing and why I always got RM IR.

I'll get the hang of Linux yet. I'm NOT going back to M$. Thanks everyone for bearing with me on this.

[Barf]

...however for some reason neither prog will exit (!?). I have to run System Monitor, where I find it's 'Waiting Channel' is 'futex_wait_queue_me' .. whatever that is, and I have to end the process from there. (Ubuntu 11.04 AMD 64bit)

This bug?. Try adding

Code: Select all

-properties /tmp/remotemaster.properties

to the command line.

I'll get the hang of Linux yet. I'm NOT going back to M$. Thanks everyone for bearing with me on this.

[gfb107]

See this post, which discusses some implementation details about the how the JP1 Parallel driver works under Linux. Maybe you can help find a solution that is not a sledge hammer.

One thing to keep in mind is that we are bit-banging the parallel port, not doing normal reads/writes.

That's why the rmir.sh and rmaster.sh scripts use gksudo

This is a sledge hammer solution that has a number of serious disadvantages: security and portability problems. Particularly bad as it is most often not needed.

[Barf]

Greg,

I looked at the sources, and as far as I can tell (I an not a device driver expert) there is probably not a chance to have that code run without root privileges. Possibly using the standard lp driver there is hope, I do not know. What I CAN offer you is this patch:

Code: Select all

*** jp1parallel.cpp	Sun Nov  6 13:52:13 2011
--- jp1parallel.cpp~	Fri Mar 27 03:49:02 2009
***************
*** 436,444 ****
  #endif
  
  #ifdef __linux
!   int success = ioperm( lp_baseport, 2, 1 );
!   if (success == -1)
!     return false;
  #endif
  
    if ( remoteif_check())
--- 436,442 ----
  #endif
  
  #ifdef __linux
!   ioperm( lp_baseport, 2, 1 );
  #endif
  
    if ( remoteif_check())

It makes jp1parallel fail instead of crashing if run without privileges, thus solving the case I wrote about in a previous posting. (I have tested.)

So my suggestion is this: Take out gksudo (the standard name, as used by e.g. Suse, however is "sudo"). Verbally tell the parallel port users that they have to run as root, and must be aware of, and accept, the security implications.

[eferz]

One thing to keep in mind is that we are bit-banging the parallel port, not doing normal reads/writes.

You get me so hot and bothered when you write things like this.

[Dilligaf]

what if you give lpt privileges to the program. It's been a while since I played with linux.

Mike

[Barf]

what if you give lpt privileges to the program.

What I did in my "code review" was to rule out possibilities of that sort. More verbosely: The code does not use a particular driver, like lp or lpt, not does it access a file or device normally only readable with privileges. Instead it "bit-bangs" bytes into raw io-locations, in a very low-level way, for example (probably?) not existing outside an x86-architecture, which the system refuses unless root, for a good reason. See the man page of ioperm.

BTW, giving privileges to a Java program definitely can be done, but is a bit more complicated...