Free Downloads, Community Forum,
FAQs and Developer Resources


Make /Tools Your Home | Link to us

Today's posts | Posts since last visit | Most Active Topics

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
  Printable Version
All Forums >> [SFU / Interix / SUA Technology] >> SFU / Interix - Getting Started >> ls: command not found Page: [1]
Login
Message << Older Topic   Newer Topic >>
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.
Post #: 1
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" .

(in reply to xolotl)
Post #: 2
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.

(in reply to xolotl)
Post #: 3
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.

(in reply to xolotl)
Post #: 4
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.

(in reply to markfunk)
Post #: 5
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

(in reply to xolotl)
Post #: 6
Page:   [1]
All Forums >> [SFU / Interix / SUA Technology] >> SFU / Interix - Getting Started >> ls: command not found Page: [1]
Jump to:





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


Search All Forums -

Advanced search


SPONSORS



Forum Software © ASPPlayground.NET Advanced Edition 2.5 ANSI

0.063