forums.ps2dev.org

I'm using the Win32 tools from the Package by 'Loser', downloaded from this site. The installation is OK, and I've compiled several working programs with it. However, some tools don't behave correctly when called by 'make', as compared to how they act when invoked manually.

For example: if 'make' invokes "rm -f *.o" then that command has no effect at all, even though it works right when I manually go into that source folder and issue the same command. Then all the object files in that folder are erased, so why doesn't it work when invoked by 'make' ?

I have tried changing such makefile commands to "rm -i *.o" or similar, to get some more details on the problem, and then I get the error message "rm: cannot remove `*.o': No such file or directory", indicating either that 'rm' has treated the asterix as a proper name rather than a wildcard, or that it has looked in the wrong directory.

The first alternative implies a bug in rm.exe, but the second implies one in make.exe instead, or even some major problem with my setup. But I doubt that it can be the latter as that should prevent the same commands from working when not using wildcards as well, which works fine.

Best regards: dlanor

PS:
My OS is WinXP Pro with SP2, which may also have some effect on all this.
DS.

Well, commands such as rm will be inside an unix-like environment, such as cygwin.

pixel wrote:Well, commands such as rm will be inside an unix-like environment, such as cygwin.

The package does contain some cygwin components, but those are launched through WinXP and execute under it, so of course what they do can be affected by it too. That's the only reason I mentioned my OS.

Hmmm. I must have missed something here. Probably something that Unix oriented people take for granted and therefore never put in the docs...
Let's see... OK I think I may have it now.

The docs I've seen all say that we must use these tools from a command line, which is pretty obvious, but it's not really obvious what it means when two types of system are involved. For a Windows user it simply means to open a command window and start entering commands, but I suspect Unix users would see it a bit differently, wanting some specific shell program to be called.

That's fine by me too, though I just wish the docs of the package would mention something about it, which they don't.

So please tell me if I'm on the right track here, and if so whether I should use 'bash' or 'sh' (both are supplied), or something else entirely.
(I'll start testing with 'sh' and see where that gets me.)

Best regards: dlanor

Well, don't take it as a troll, but, I'd suggest you to go under a plain unix :)

All the toolchain is meant to run under unix actually. So, yes: "docs" (as much as docs are available) will assume you are running unix, and that you are used to that. There is no real plain "windows" support; only hacks using cygwin. So, well, the whole toolchain should work straight under a true unix. I'd even suggest you to try colinux, if cygwin is bothering you. You'll have a true linux distribution running under windows.

To answer your question, bash and sh should be basically the same things, if not sh beeing an alias for bash.

I've now tested 'sh' as the shell for launching 'make', but though it did improve some other things, it didn't improve the problem. Asterix wildcards still do NOT work in commands invoked by 'make' though they DO work when the same commands are entered into the shell manually.

Is it possible that 'make' itself uses the wrong shell for its commands ? And if so, how can I take control of that ?

pixel wrote:Well, don't take it as a troll, but, I'd suggest you to go under a plain unix :)

No, I take your advice as well-intended, but switching to Unix is simply not on. I've used it before, so I know that this would force me to twiddle around with the OS itself and its tools for a LONG time, before getting to use it for the things I really want to do (like PS2 stuff).

All the toolchain is meant to run under unix actually. So, yes: "docs" (as much as docs are available) will assume you are running unix, and that you are used to that. There is no real plain "windows" support; only hacks using cygwin. So, well, the whole toolchain should work straight under a true unix.

Understood, but it should still be possible under Windows too if the tools are made to work right. They're damn close as it is, so it would be a sad waste not to push them on to go all the way.

And the doc I meant was the one of the Win32 PS2DEV package, as that is where advice for non-Unix users is obviously needed.

I'd even suggest you to try colinux, if cygwin is bothering you. You'll have a true linux distribution running under windows.

That sounds very interesting as such (unlike cygwin), but at present my interest is to spend time on PS2 stuff, not on new OS variants. Having two OS in the same box should lead to even higher maintenance demands than Linux makes on its own, so I think it would steal too much of my time.

To answer your question, bash and sh should be basically the same things, if not sh beeing an alias for bash.

They're obviously similar, as Bourne made both, but he wouldn't make two shells if they were identical. The binaries I have are certainly different (515KB vs 73KB), though I haven't checked how much of it is due to debug symbols etc.

There's also an obvious difference in functionality, as sh.exe worked fine from first attempt, whereas bash.exe gives an error message when launched, complaining about a missing /tmp. AFAIK that is not a legal cygwin path, so there is no way to satisfy that demand, unless it can be done with symlinks somehow...
I suppose it must be homesick... (for Unix I mean ;) )

Best regards: dlanor

I have now tested the wildcard problem extensively, and found that three binaries (at least) have the same bug: rm.exe, mv.exe, cp.exe. When called by make with an asterix wildcard in argument (eg: '*.o') each of them will fail to find the files referred to. Surprisingly,however, cat.exe does NOT suffer from the same problem...

For my own needs, I've solved this by hiding those three exe files, so the system seeks further in the PATH until it finds an old DJGPP package with matching files that work better (though it is a VERY old DJGPP setup).

Others who need similar functionality can of course do the same thing, though the best thing for all would be if someone with a modern DJGPP or CygWin setup could make better versions in modern form. (The old ones I have use an outdated PE format, but work fine.)

sh.exe also has some problems, most notably that it doesn't seek executables in the current work directory before looking in PATH. Files in the cwd can only be executed properly by sh.exe if the string ".:" is explicitly prepended to the PATH (ie: "PATH=.:$PATH").

Another problem is that it is also necessary to explicitly set up the variable "SHELL=sh", to avoid falling back to CMD.EXE of Windows when make.exe invokes the compilers and other binaries.

Both problems with sh.exe were easily solved by adding some lines to the batches I use for all PS2DEV work, which means that ALL of my major problems are now solved... :)

Most sources (and ALL modern ones I think) now compile quite well without any major changes being needed (except for really old ones). I even got the 'Funslower' to work fine, which would have been impossible for me a few days ago.

I have prepared a package with the batches I use, allowing much of my work with 'sh' to be done by dragdrop, rather than by tedious typing. If anyone else wants this I'd be happy to post it. But if everyone else here is using Unix boxes I guess there would be little point in dong so...

Best regards: dlanor

Wildcards are usually extended by the shell. That is, if you type "rm -rf *.o" using bash, it will extend it to "rm -rf <list of the .o files, separated by spaces>" automatically. So, if "make" doesn't use bah as shell, you most probably will run into the problem you described (and it seems you are running cmd.exe instead if sh.exe)

And for the shell not looking in the cwd, that is ganz normal: it is a well known security issue to not run commands in the working directory. And the "best" way is really not by prepending . in the path, but adding it at the end: PATH=$PATH:.


Now, you can still post some packages/fixes/docs/etc that could be useful for newcomers.

pixel wrote:Wildcards are usually extended by the shell. That is, if you type "rm -rf *.o" using bash, it will extend it to "rm -rf <list of the .o files, separated by spaces>" automatically.

For Unix I assume you know better, but as implemented for these Win32 tools it simply isn't so. Each exe file handles wildcard expansion on its own, but for unknown reasons some of them fail in this when invoked by 'make', even if that is done through sh.exe or bash.exe .

So, if "make" doesn't use bah as shell, you most probably will run into the problem you described (and it seems you are running cmd.exe instead if sh.exe)

That was indeed the case in my early attempts, but as mentioned in my last post I now use the SHELL evironment variable to ensure that the same shell is used consistently, not only for my manual launching but also for the invocations made by 'make' and GCC etc.

And for the shell not looking in the cwd, that is ganz normal: it is a well known security issue to not run commands in the working directory.

Perhaps we're talking of two different things here. If I open a command window in a folder and type the name of a program that's in there, then it should certainly start. How can that be a security issue ?

And the "best" way is really not by prepending . in the path, but adding it at the end: PATH=$PATH:.

I can see the point, though I don't think it matters much either way. It will only be used for the PS2DEV tools, not for the system as a whole.

Now, you can still post some packages/fixes/docs/etc that could be useful for newcomers.

Ok, I might do that then, except that I don't know how...
I can't see any buttons for attachments here, so I guess they're disabled.

Best regards: dlanor

Yes, we are talking of two completely different things here:

-) you are under windows, and thus, you are using "cmd.exe" as shell, which has quite no clue about security or whatever. And which has no clue about wildcards. So, the software you are running under native windows are doing wildcard expansions. For example, deltree, del, move, copy, etc..

-) now, you are using unix-like stuff, which are usually running under a plain unix. The normal shell is sh or bash, and is aware of security, and does wildcard expansion. So, software running under unix are not aware of wildcard expansion at all, since they believe the shell will take care of that for them. That is, native UNIX softwares like rm, cp, mv, ... won't do any wildcard expansion, even when run from cmd. So, if you run rm.exe (which IS a unix tool ported to windows, not a native windows tool) from cmd.exe, this will most likely fail if you use wildcards.

Moreover, there is a very well known security issue about having . in the path under unix, especially when you are root (administrator under windows). Say you unpack some software from the net, and that it contains a malicious software called "ls"; then, if you type "ls" in the directory's package to list the files contained in it, you are running the malicious software. So, that's why bash or sh won't have . in the path for administrators by default. Note the same security issue occurs under windows. Microsoft simply assume nobody ever use the command line (which is quite true)

Of course, this is quite not a huge issue under ps2dev, but I consider this is something to know when doing "unix" in any form.

Now, if you have some changes to post, don't you have any webspace at all anywhere ? If not, well, we can still try to work out something.