ID:1808737
 
We are using that function to get some logs.
There's no instructions at run reference on what proc should be used.
You should probably be using file2text() and outputting it to a browser window or something.
run() was removed from the latest version of beta, try downgrading.
You can use a work around of using shell() to open the file.
I'd have to know what exactly you were doing with run() to suggest an alternative, but basically you shouldn't need it at all for basic file I/O. And I don't see what purpose it would have for logging, as run() is a client-side operation.
ss13 has quite a bit of logging to do for administration. run is used when an admin requests any sort of permanent log rather than one that just exists for one round. Why was this abruptly removed without mention in the damn changelog? I appreciate you finally getting 1276 out but come on this is completely uncalled for just removing a feature randomly with no warning.

Just to re-iterate on how horrible it is to have run() removed, trying to search through a 12mb log within the game using a browser element is painfully slow as something more robust like notepad++ makes the task much simpler.
Yes, This is used when admins request logs.

The file is sent to the client, and opened with notepad via run. (i'm not sure on the exact details)

The files are way too big to be displaying to the client in the browser window, as well as the fact that we have external tools to parse these logs for cross referencing.

What your suggesting, is that now the new workflow for accessing the log files should be, display a 5 to 8 mb file to the user in a browse(), they copy and paste that into notepad, save it, than open it again with logfile analyzer, than do it again with the 2 to 3mb attack log file?

You basically removed a feature that every tgstation13 branch (tgstation13, baystation12, vgstation, paradise station, most of the ones on the hub for ss13) used multiple times a day.

Also: it's generally bad form for a language to "deprecate" a built in function/variable/class object without offering some sort of replacement, thats not how depreciation works. Depreciation refers to the "old" way of doing things. This can't be the old way of doing things if no new way exists.

Is there any version of DS that this will not work in (i'm assuming 1276 and up?), as we will need to tell our admins not to update as well as our server hosts.
Heres an example of a log file that is shown in game currently but also archived for public viewing, at the end of the day this log becomes quite annoying to search through in game. http://ss13.pomf.se/logs/2015/03-March/06-Friday%20hrefs.htm And here is the normal log which is typically viewed via run() http://ss13.pomf.se/logs/2015/03-March/06-Friday.log

@MrStonedOne officially run() was deprecated in 1275 but I was on 1275 for a while and saw no issue, it wasn't until 1276 did it stop working and warn deprecation.

http://www.byond.com/ forum/?post=180952&page=12#comment14315338
Tom wrote:

In this release, we've disabled the old run() functionality which I don't think anyone used (it required a confirmation anyway).
The reason we have chosen to remove run() is that it cannot be supported in the webclient, and we's like the code to be portable. I admittedly did not believe that anyone was using it. You can stay on 1274 for the time being.

We'll need more detail on exactly how you're using run here. I don't see how opening a file in notepad is any different than in the browser. If you are preprocessing the file, I don't see how that can be reliably done on the client (via run) unless it is also running as a server (in which case you should use shell), since the client would have to have the necessary tools on board.

We can always restore this and make the deprecation a 'warning', but I'd prefer to push devs into using the portable way of doing things. So don't freak out and we will figure it out.

In response to Tom
Tom wrote:
The reason we have chosen to remove run() is that it cannot be supported in the webclient, and we's like the code to be portable. I admittedly did not believe that anyone was using it. You can stay on 1274 for the time being.

I'd rather not go back to 1274 due to the recent serverside bug fixes in 1276 namely the profiler crashing the server and the luminosity buffer overflow.

We'll need more detail on exactly how you're using run here. I don't see how opening a file in notepad is any different than in the browser. If you are preprocessing the file, I don't see how that can be reliably done on the client (via run) unless it is also running as a server (in which case you should use shell), since the client would have to have the necessary tools on board.

We can always restore this and make the deprecation a 'warning', but I'd prefer to push devs into using the portable way of doing things. So don't freak out and we will figure it out.

As much as I understand you want portability and compatability between the webclient and normal seeker the removal was quite unfounded but you seem to get that now.

Opening a large text file in a browser element in seeker causes a good deal of client side lag when scrolling through or searching for a string. The ability to load it on the clients computer with their predefined text editor of choice gives the person a lot more control over the document. As mrstonedone said above they utilize a parsing script that is ran on the client after obtaining the log file to scan for pertinent data. I personally make good usage of regex searches with notepad++. Neither are available if we just do file2text and browse() it to the client.
Well, like I said we can always restore it in the next release for the time-being. There's a more critical related link bug we need to patch asap anyway.

Ultimately, I'd rather have a more portable solution. Perhaps we can have the webclient run set the mime type to deliver the file as a download, so that (ideally) the client can the open it however they'd like.
If you're going to just make it download the file, you can probably just ftp() it to the client.
mrstonedone ftp() does what you suggested, until run() comes back i just added this to the log retrieval code
    #ifdef RUNWARNING
#if DM_VERSION > 506
#warn Run is deprecated and disabled for some reason in 507.1275/6, if you have a version that doesn't have run() disabled then comment out #define RUNWARNING in setup.dm
src << ftp( file(path) )
#else
src << run( file(path) )
#endif
#else
src << run( file(path) )
#endif
run() is reinstated in 1277, but I would generally recommend against using it, as we may remove it (again) in the future, and if we don't, behavior will differ between DS and the webclient. We'll try testing my suggested proposal where, for the webclient, it can deliver the file as a download (regardless of type), where presumably the browser will then prompt to execute. Nadrew's ftp() suggestion is also an excellent alternative, although note that currently ftp(), like run(), isn't supported in the webclient (I think it should be possible to prompt for a download location and deliver the file though).