Tonite there was a brief discussion about the possibility of ooPo adding a feature to ps2client where he checks the filename passed into execee or execiop, and if there is no ":" (device specifier) ps2client would automatically prefix "host:". This would be a lazy way to load ELFs from host.
ooPo maintains that "Let the user figure out what he/she wants to do" and that ps2client shouldn't try to guess what the user would want it to do. I'm of the opinion that the most common way to load ELFs is via host:, where ooPo says:
ooPo wrote:I don't think host: should be the default. On a cd-based system.
.
I'm curious, where do folks load their ELFs from? host: or somewhere else?
Please, can you at least quote the part that's important? I do not want to try to outguess the user. This ps2client is supposed to be a simple tool that does what you tell it... its bad enough that nport requires some fooling with slashes and other munging of data that has to be done to get things to work.
Regardless, I've always maintained that if enough people bug me about it I'd change it... I'm actually quite surprised people are using it in the first place with the cold reception it got at first. So, please vote... I'm kind of interested in the results myself.
To me it seems that while developing and testing you are almost always going to be running your app from host: and the others won't really be used until you are ready for release.
IMO it's a reasonable assumption that if you are too busy to remember to add the device prefix that you are actively working and 99.9% of the time loading from host. In the cases where you want to load from somewhere else you are going to be thinking about where you want to load from so forgetfullness won't be as much a problem ;)
ooPo: I hope you don't take any of my comments to be cold or negative, I very much like ps2client and think you've done a great job with it.. I'm just prodding for a feature I'd like to see ;)
Ok, since I brought up this thread, I think this is a good place for my first post.
IMO think that a default destination of host would be good, because I support Drakonite's theory and then it would also be more *nix like. Unix programs tend to have switches, commands and arguments. So ps2client would be more intuitive to use if it had the format:
"ps2client command file" instead of "ps2client command host:file"
When I'm doing code, I have a very simple command.
make run
If you're typing the whole command out each time you want to run your code when you can have a makefile do it for you... then I suggest that further finger optimization is currently in your hands, not mine. :)
I developed it to be run in a makefile. I added support for it to run in a script. This is what its for. Its not a pksh clone. Running it by hand should be the last resort to run simple one-time commands like running the latest TTC entries. If you are running into problems having to type host: all the time you are using it wrong.
It would be very easy to write the code to do this. It really isn't a big deal. I just have yet to hear a real argument besides 'oh but its a pain to type it'. What if I response with 'oh but its a pain to code it'? It doesn't seem like its a pain to discuss it at any rate.
As for being more unix-like? How much more unix-like can it be? Its a simple, command line program that does one thing but does it well. What other unix-like programs try to second guess the user?
pksh already prepends host: to all arguments that it finds as files on the host system ie, if argv[n] == file and no host: prepend host:, quite simple,
and it do have the simple commandline tools so you can execee from your editor/Makefile etc ( which seems to be an issue whenever ps2client is measured against pksh ).. adding that logic to ps2link might be a bit fudgy, even if you only add it to the first param, ppl adding filenames as argn to the exec would need to add host: for those params that is a file, leave it to the client who actually can figure out if argn is a file or not.
Last edited by blackdroid on Fri Mar 19, 2004 4:48 am, edited 1 time in total.
ooPo wrote:It would be very easy to write the code to do this. It really isn't a big deal. I just have yet to hear a real argument besides 'oh but its a pain to type it'. What if I response with 'oh but its a pain to code it'? It doesn't seem like its a pain to discuss it at any rate.
Actually, it's less of an argument about laziness and more of an argument about expected behavior, esp. for folks (like me) who've spend a insane amount of time with pksh. I was also bitten when I was first testing out ps2client, I forgot to add host: and it took me a few minutes to figure out what was happening.
Newbies expect it because they don't realize that the IOP is really the one doing the physical loading, and that the client is just responding to open() and read() requests. When they go to load a file, they think that ps2client is loading it, so that specifying just the file name is enough. It's not about ps2client trying to outguess what they are trying to do, it's more of ps2client doing what the user expects it to do.
Would it be difficult to not prefix in the code the files (IRX and data files) location and add a command line arg to psclient like -host cdrom0,mc0,... to configure pslink search path ?
I really struggle with this, so many demos cannot run on my PS2 due to hardcoded cdrom0....
I don't think that ps2client should stick "host:" in there without asking - it's an important lesson for newbies to learn why it needs to be in there anyway.
How about a command line switch that enables lazy mode? --lazy-host --lazy-cdrom, whatever? Or even just print a warning to the user when no ":" is found in the filename, that at least improves on the current situation whereby people try, fail, and come asking why.
It should say on your ps2link screen that it can't open the file.
As for hardcoded cdrom0, that isn't a function of the client. If ps2link wants a file from somewhere other than host:, it'll ask the IOP for it - not the client.
