All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
ls: command not found
|
Logged in as: Guest |
Users viewing this topic: none |
|
Login |
|
|
ls: command not found - May 3, '03, 5:49:03 PM
|
|
|
xolotl
Posts: 3
Joined: May 3, '03,
Status: offline
|
I am new to Interix, so apologies if this is dumb
but I just unstalled bash from the tools warehouse,
I created a shortcut for it by copying the ksh one
and adjusting the executable name + path and now
for all non built-in commands, e.g., ls, I get " ls:
command not found" , even though /dev/fs/C/SFU/common
is in PATH. What gives?
Thanks in advance,
-- O.L.
|
|
|
RE: ls: command not found - May 3, '03, 11:15:22 PM
|
|
|
markfunk
Posts: 670
Joined: Mar. 31, '03,
Status: offline
|
1. The shortcut for ksh (as shipped) uses the -l command line argument. This is necessary so that you get a " login" shell which will read the /etc/profile file. It is the /etc/profile file that sets up your environment variables properly for the Interix/Unix environ that you want.
Bash does not support " -l" . It uses " --login" instead.
2. Your environment is not set properly without --login. Without --login you just get environment variables inherited from the Windows global environment variables. These aren' t sufficient to get you fully into a UNIX environ. To enter into the UNIX environ that Interix provides, you need to do what /etc/profile does.
3. /dev/fs/C/SFU/common is the directory one uses if one is a Window' s user - not a UNIX user. Take a look at the files in this directory. They all end in " .exe" . It contains Windows binaries and specially modified Interix binaries that know how to deal with Window' s pathname syntax.
If you want to be in a UNIX environ you need PATH to contain a minimum of " /bin:/usr/contrib/bin:/usr/local/bin" .
|
|
|
RE: ls: command not found - May 4, '03, 9:10:52 AM
|
|
|
xolotl
Posts: 3
Joined: May 3, '03,
Status: offline
|
Very clear explanations. Thanks a lot! However now
I observe the converse problem that *.exe binaries
cannot be found, even though /dev/fs/C/SFU/common
is still in the PATH. This matters, e.g., for ' which' ,
which is apparently only available as a win32 binary
and a very useful utility.
The problem seems to be that bash is not smart about
the *.exe suffix because ' /dev/fs/C/SFU/common/which'
yields " No such file or directory" whereas, as expected,
' /dev/fs/C/SFU/common/which.exe' works. Is this a runtime
configuration issue or an oversight when modifying
the bash sources? ksh does not have this problem.
-- O.L.
|
|
|
RE: ls: command not found - May 5, '03, 9:29:43 AM
|
|
|
markfunk
Posts: 670
Joined: Mar. 31, '03,
Status: offline
|
correct.
When using Interix shell and utils, you are in a UNIX environ. This means you get the same behaviour you do on any other UNIX system. You have to type exactly what you want. Using suffixes that give clues as to the purpose or contents of a file (ie. .exe for executable programs) is a Windows specific feature. For this to work, you need specially written shells (cmd.exe, explorer.exe, ..) that know how to recognize and interpret filename suffixes. UNIX doesn' t have this " problem" .
UNIX shells are much more flexible in allowing the user to define their own working environment. Yes you could type " which.exe" . Or you could create an " alias" like " alias which=which.exe" . Or you could choose one of a handful of other mechanisms that will cause the shell to recognize a " which" command that actually executes the " which.exe" in /common.
Having said that, Interis ksh (and only ksh) was modified (after much heated discussion) to support a mechansim that will automatically detect special suffixes when searching for executable programs. This mechansim is enabled and controlled by an environment variable called PATH_WINDOWS.
PATH_WINDOWS is explained a little bit (but not completely) in the help topic " Starting a Win32 program" in the SFU Help.
NOTE: Do not look in the SFU3.0 ksh.1 man page. The information here is completely wrong.
Other notes:
/common contains programs for Windows users. If you' re using Interix, then only use programs here if you' re comfortable using Windows programs in a UNIX environ.
/common/which.exe is a Windows program. It will return Windows pathnames. Pathnames that aren' t usable in the Interix environ. You probably want to get the UNIX source code (from ftp.openbsd.org) and build your own with Interix SDK tools.
|
|
|
RE: ls: command not found - May 5, '03, 9:52:59 AM
|
|
|
xolotl
Posts: 3
Joined: May 3, '03,
Status: offline
|
_A priori_ it is not unexpected that a Unix environment
would not know or even care about Windows extensions.
However I had read somewhere that strong integration with
Windows was a design goal of the original Interix, so the
ksh behaviour was the expected one in this case. Anyway
now all is clear. I will probably try to compile which
from sources indeed, almost certainly a useful exercise
for an Interix newbie ;-)
-- O.L.
|
|
|
RE: ls: command not found - May 5, '03, 11:33:58 AM
|
|
|
markfunk
Posts: 670
Joined: Mar. 31, '03,
Status: offline
|
" Integration" has so many different interpretations and expectations. Just to make sure your expectations are set properly, in the original Interix' s case, it was more like " will play well" with Windows. The primary goal for Interix was providing a faithful UNIX implementation and environment on Windows. A separate environmental subsystem was used to be protected from the UNIX incompatibilities of Windows. But we couldn' t be completely isolated from Windows. There had to be some integration with underlying Windows features.
Like pipes, shared memory, some Interix utils support both DOS and UNIX text file formats, and special utils like /bin/runwin32 and in /usr/contrib/win32/bin/.
There is a limit to how much can be ' integrated' . That' s why \ character as a pathname separator or the UNC syntax of //server/share isn' t provided in Interix.
Other UNIX-like products on Windows take a different approach - they want to integrate much more closely with Windows so they build their UNIX environment on top of the Windows subsystem and they embrace the Windows look and feel rather than hide it. The goal here is to allow as much UNIX functionality as possible but without sacrificing Windows compatibility. Or rather sacrificing UNIX semantics in order to preserve Windows functionality.
It' s a trade off. Different products for different user' s needs. Each have their strengths and weaknesses depending on your requirements.
_____________________________
Mark Funkenhauser - Independent consultant
Interix co-creator
|
|
|
New Messages |
No New Messages |
Hot Topic w/ New Messages |
Hot Topic w/o New Messages |
|
Locked w/ New Messages |
Locked w/o New Messages |
|
Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|