.ksh file association

[iowa_don]

I just recently "upgraded" from Windows XP to Windows 7 64 bit. On windows XP my k shell file scripts with a ".ksh" extension had the little pyramid icon and when I double clicked them they would start a k shell and run. After installing SUA on my new Windows 7 machine those files no longer have the pyramid icon and I can't figure out how to associate them the way they were under Windows XP. Any help will be greatly appreciated.

[cbhacking]

I don't know if this is the best way, but...
The following Windows command will execute any POSIX script passed to it. You could probably put this directly into HKCR (as the value of the \shell\open\command; you can definitely put it into a .CMD file.
posix /u /c /bin/sh -l -c "`winpath2unix '%~f1'` '%2' '%3' '%4' '%5' '%6' '%7' '%8' '%9'"

There's probably a way to clean that up some, or make it handle other input more gracefully, but it works well enough.

[CerysDunn]

(2012-07-11 04:27 PM)cbhacking Wrote:  I don't know if this is the best way, but...
The following Windows command will execute any POSIX script passed to it. You could probably put this directly into HKCR (as the value of the \shell\open\command; you can definitely put it into a .CMD file.
posix /u /c /bin/sh -l -c "`winpath2unix '%~f1'` '%2' '%3' '%4' '%5' '%6' '%7' '%8' '%9'"

There's probably a way to clean that up some, or make it handle other input more gracefully, but it works well enough.

I can not quite understand and then put code in the CMD and then run this inside?

[rodney]

Yes, you put the command line:
posix /u /c /bin/sh -l -c "`winpath2unix '%~f1'` '%2' '%3' '%4' '%5' '%6' '%7' '%8' '%9'"
in a ".CMD" file or at the Windows CMD shell command line.

When you look at the Shortcut in the in the menu for starting a shell (look at the Properties panel) then
you can see it is similarly done.

[cbhacking]

Alternatively, open a CMD or PowerShell window as admin (you can also do it from an Interix shell, but may have to deal with weirdness around character escaping). Enter the following lines exactly as given here (unless you need to adjust the path to posix.exe):

Code:

assoc .sh=InterixScript
assoc .ksh=InterixScript
ftype InterixScript=C:\Windows\posix.exe /u /c /bin/sh -l -c "`winpath2unix '%1'` '%*'"

That will set the file association in the registry. You can then double-click the scripts to have them execute.

[dlandis]

I'm having the same trouble going from XP to win7 with .csh scripts. My file type for .csh on XP is:

CShellScript="C:\SFU\bin\tcsh" -l -c "\"`/bin/winpath2unix '%1'`\" %*"

But this does not work for win7. It complains about the "-l" option. I just want to be able to use a cmd window and execute .csh scripts. I also want it to remember my location and not change to $HOME and keep my $PATh so it will find my programs. I believe these are changes that need to be made in files under /etc but I'm not sure which ones since things are different for win7. Sorry if I'm not versed well with this but do need help getting it set up. Thanks

[rodney]

This result is the standard for csh and tcsh for many, many years.
From the tcsh manual page:

Code:

-l
     The shell is a login shell. Only applicable if -l is the only flag
     specified.

So you cannot specify another flag with the '-l' (small ell) flag.

Even if you did change tcsh to allow '-c' and '-l' at the same time,
the specification that it's a login shell (-l) dictates it start from the
home directory and that PATH be set to an initialized state (actions you
are asking not to happen).

Historically the reason for this decision is to reduce the start up load for
a script. People typically have various command aliases and env vars set
that take time -- and most script don't need them.
What you can do is create a separate file that has the minimum configuration
actions you need and then at the start of your script use the source command
to get it picked up. By having it in a separate file you can then reuse it with other
tcsh/csh scripts.

[dlandis]

Thanks Rodney for responding. I think I understand what you're suggesting. I'm just not that up on the whole invoking shell procedure. What I think you're saying is making a line that invokes the shell? And then put that line at the start of my scripts? What would the scripts then be? A .bat or .cmd? That line would have some kind of command similar to the ftype from XP but not sure what it should be. I would like to be able to start the script in a cmdtool that logs into the shell and passes command line variables (arguments) from the cmdtool into the shell. So should it be a posix.exe or a tcsh with what parameters? Doesn’t the shebang at the top of all my scripts get invoked somewhere? Like I said, I’m not very literate on these procedures. I never had to worry about it in XP with SFU. WIN7 didn't seem to do any of this .csh or .sh file setup.

As for setting of the $HOME directory I found it in csh.login where I just needed to comment that part out. I also saw I had to include $PATH_ORIG into $PATH to keep my directory of programs in the shell. However, the above command line we’re talking about needs to log into the shell with the –l (ell). Passing cmd line variables could be tricky or is that the %* part? Anyway I need lots of help with this. Thanks again for your attention.

[rodney]

It may help to get a text on the shell. There are some on-line references too.

"Sourcing" a script can be done with all of the Unix shells. How it is done in each is a little different, but
each gives the same result: whatever actions happen in the sourced file become set in the current shell or script.
When a shell is in 'login mode' it will look automatically for certain files to source. These will be in /etc and
the users home directory.

I'll write specifically about tcsh/csh from this point for syntax, but it can all be done with ksh, zsh & bash too (I mentioned this because this thread was about ksh file associations and it's now
drifted).

Let's created two files named "common" and "myscript". In "common" we'll have:

Code:

echo "At start of common"
setenv PATH "/usr/local/bin:/usr/bin"
set src="/dev/fs/C/source"
set xxsrc=$src/xx
echo "At end of common"

and in "myscript" we'll have:

Code:

#!/bin/tcsh
echo "At start of myscript"
source /etc/common
echo "PATH is now ${PATH}"
echo "At end of myscript"

When you run "myscript" it should display "At start of myscript", then source the "common" file which will
result in your seeing the echo statements in "common". Returning from "common" should have "myscript" display
the value for PATH that was set in "common".

You want to leave the /etc/csh.* files alone. Otherwise you're going to mess up a regular login shell.
Copy what you want to happen into the "common" file that will get sourced. Then all of the actions you
wanted to happen with "-l" (small ell) will be done without needing that flag. You'll also not get changed
to your home directory. If you don't want PATH changed then don't change it -- I just used that as an
example of something to do -- PATH will be inherited from whatever environment it was started from.

The result will be:
- you can start the script from CMD
- the script will inherit PATH from the CMD environment
- the common source file will set things as you want
- the common file can be reused for other scripts

Just start the script as you did before but without the '-l'.
The "%*" is shorthand for all of the options.

As a sidenote: you can invoke winpath2unix directly; you don't need to have a shell run it.

[dlandis]

Thanks again Rodney. You gave very good detailed response which helps me a lot. I’m still having issues with the setup in WIN7 OS. I thought the issue was that after turning on the SUA and installing the tool package, WIN7 should have known what a .csh files was, i.e. all my scripts. When I executed one in a cmd tool it came up with the usual window of what do you want to assign to a .csh file. Then I saw commands in this thread from cbhacking using the assoc and ftype windows commands to set this up, I thought I just had to change "sh" to "tcsh" which then got my .csh scripts to execute but give the error on the -l option. So I assume your suggestion is to take that option out and reset ftype to this.

ftype InterixScript=C:\Windows\posix.exe /u /c /bin/tcsh -c "`winpath2unix '%1'` '%*'"

This sort of works in that I now can execute my scripts but appear to be running into problems with the unix to dos issue. Like when I output a file in the script it creates a dos file not a unix file. Even my variables are messing up with those extra characters. When executing the script in a c-shell they “appear” to not have this problem but have others. Anyway it makes me think I’m still not fully executing a cshell script from a cmd tool. Maybe I just can’t get there. Things have changed too much with SFU to SUA and MS is just not dealing with all the issues. My scripts appear to need a lot of work to make them move from SFU to SUA. I think my history of executing unix scripts in windows OS is coming to a close and I need to move on to some other scripting language like Perl or Python or maybe Powershell if I want just windows. So thanks anyway for your help.