Re^2: Problem with qx/system and long urls

Thanks for your answer! I used GET because I wanted to have bookmarkable urls, so I could rerun the simulation again and again, or even send the link to another person who could then run the simulation on his computer, by simply clicking the link. So I guess I have to find a workaround for this. By using HTTP POST, I'm not able to bookmark the urls anymore. Does the linux shell (bash) has the same limit, or can environment variables be undefinitely big? I could start the server in cygwin or even vmware with linux then.

Comment on Re^2: Problem with qx/system and long urls

Replies are listed 'Best First'.
Re^3: Problem with qx/system and long urls by philcrow (Priest) on Apr 24, 2007 at 17:10 UTC
Could you collect the data that is in the post into a database row and give people that row id as a token in a single query string param? Phil The Gantry Web Framework Book is now available.	[reply]
Re^4: Problem with qx/system and long urls by bluelu (Initiate) on Apr 25, 2007 at 08:44 UTC
That would be a possibility. I intented however to start the server localy on each server. But I will probably move to a centralised approach after all.	[reply]
Re^3: Problem with qx/system and long urls by Anonymous Monk on Apr 25, 2007 at 13:06 UTC
`{ local %ENV = map { $_ => "$ENV{$_}" } qw{ ALLUSERSPROFILE APPDATA COMMONPROGRAMFILES COMPUTERNAME COMSPEC FB_FILE HOMEDRIVE HOMEPATH LOGONSERVER OS PATH PATHEXT PROGRAMFILES PROMPT SESSIONNAME SYSTEMDRIVE SYSTEMROOT TEMP USERDOMAIN USERNAME USERPROFILE WINDIR }; print qx{ dir }; }` [download]	[reply] [d/l]
Re^4: Problem with qx/system and long urls by bluelu (Initiate) on Apr 26, 2007 at 12:19 UTC
++. That's exactly what I needed :-)	[reply]