| | <<<Back 1 day (to 2019/09/16) | Fwd 1 day (to 2019/09/18) >>> | 20190917 |
| rnissl | Hi, kens -- looks like there is a regression with rc2 | 10:09.47 |
| kens | OK..... | 10:10.01 |
| | What ? | 10:10.03 |
| rnissl | looks like command "switch" @filename doesn't work anylonger | 10:10.20 |
| kens | Have you added the directory where the 'filename' resides to the reading list ? | 10:10.49 |
| rnissl | it's current dir | 10:10.59 |
| kens | I'll have to check this with chrisl, but current directory isn't special | 10:11.19 |
| rnissl | error message: Unable to open command line file @filename | 10:11.19 |
| chrisl | It shouldn't need to be added to the list, it's before the permissions are activated | 10:11.33 |
| kens | Hmm, well I'll have to try it, give me a second. | 10:11.48 |
| | It works for me on Windows | 10:13.28 |
| | I'll boot up a Linux | 10:13.40 |
| rnissl | windows is ok | 10:13.50 |
| | no need to test linux in my case | 10:14.01 |
| kens | Hmm, well it worked OK for me, my @file was pretty simple: | 10:14.37 |
| | -dBATCH -dNOPAUSE test.pdf | 10:14.37 |
| chrisl | Works for me on linux | 10:14.49 |
| kens | Tried the RC2 that works as well for me | 10:15.03 |
| | rnissl, so I guess we need to know what the content of the file you are using is, and its name | 10:15.40 |
| rnissl | gs9.28>.\bin\gswin32c -I.\lib -I.\fonts -q -dNOPAUSE -dBATCH -dNOSAFER -sPAPERSIZE=a4 -sDEVICE=pdfwrite -sOutputFile=.\output.pdf -r600 -dDoNumCopies -dDownsampleColorImages=false -dCompatibilityLevel="1.7" -dDownsampleGrayImages=false -dDownsampleMonoImages=false -dAutoFilterColorImages=false -dAutoFilterGrayImages=false -dColorImageFilter=/FlateEncode -dGrayImageFilter=/FlateEncode -dColorImageDownsampleType=/Bicubic -dGrayImageDownsampleType=/Bicubi | 10:17.15 |
| | c -dMonoImageDownsampleType=/Bicubic -dAutoRotatePages=/All -c 3000000 setvmthreshold .setsafe -f @pathNamesUtf8.txt | 10:17.15 |
| kens | Couldn't you simplify that a little ? | 10:17.41 |
| rnissl | will do to locate the issue | 10:17.58 |
| | gs9.28>.\bin\gswin32c -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=.\output.pdf -c 3000000 setvmthreshold -f @pathNamesUtf8.txt | 10:22.57 |
| | the offending part is "-c 3000000 setvmthreshold" | 10:23.19 |
| | if I remove that part of the command line, it works | 10:23.35 |
| kens | I'd put the PostScript code between "" | 10:23.46 |
| rnissl | gs9.28>.\bin\gswin32c -q -dNOPAUSE -dBATCH -sDEVICE=pdfwrite -sOutputFile=.\output.pdf -c "3000000 setvmthreshold" -f @pathNamesUtf8.txt | 10:24.41 |
| | doesn't work either | 10:24.52 |
| kens | OK sorry I'm in 2 conversations and a Stack Overflow reply at the moment, I'll give it a try in a second | 10:25.22 |
| chrisl | Oh, yep, that'll be the access controls :-( | 10:26.04 |
| kens | I sort of suspected it woulld be | 10:26.38 |
| chrisl | Obviously, we have to initialise the interpteter to process the -c stuff | 10:27.19 |
| kens | Ah, yes, that will do it. | 10:27.54 |
| chrisl | We should just drop any attempt at security and tell people to suck it up...... | 10:29.00 |
| kens | The only solution I can think of to that is to preprocess the entire command line and add the '@file' to the permitted reading list before processing the -c...-f code | 10:29.06 |
| | Or we could just say that -c and @file are incompatible. Is there a reason not to move the @file to before the -c, or to not put the -c inside the @file ? I assume that would work, I haven't tried it | 10:30.50 |
| chrisl | I assume because the @file contains the input file | 10:31.14 |
| rnissl | chrisl, it contains additional input files | 10:31.43 |
| | but I could change the command line to just a single @file, just as kens suggested | 10:32.12 |
| kens | I'm not certain that would work, I haven't tried it, but it might | 10:32.32 |
| | I was sort of thinking out loud about how we should tackle this. Whether its even possible for us to make this work, or if we have to document the limitation | 10:33.03 |
| chrisl | It's not a usage of the @ syntax that was intended, I wouldn't think | 10:34.01 |
| kens | As I understand it, teh @file intention was to enable command lines to be used which exceed the OS limitation on command line lengths | 10:35.04 |
| chrisl | But I assume it was intended for command line options, rather than input files | 10:35.36 |
| kens | Possibly Windows was 256 bytes at some point, or soemthing like that. DOS would have been short for sure | 10:35.37 |
| | No, full command line, if you have several files with long paths, they can easily exceed a short command line | 10:36.07 |
| chrisl | The problem is, after a "-c", most -d and -s options will have no effect | 10:36.46 |
| rnissl | kens, that was true in my case when there where a lot of additional input files | 10:37.04 |
| | what about this sequence: -dNOSAFER -c 3000000 setvmthreshold -f mailFilterText.ps -c .setsafe -f input.ps | 10:37.09 |
| kens | Absolutely true, I would 'expect' all the command line optiosn, and teh intput filenames, to be in the @file normally | 10:37.16 |
| | rnissl that would probably work, we're really just discussing how/if we can address this in the general case | 10:38.00 |
| rnissl | will -c force safer, so that mailFilterText.ps is unable to do unsafe stuff? | 10:38.27 |
| kens | -c causes the PostScript interpreter to start up, that will 'freeze' the directory permissions at that point | 10:39.01 |
| chrisl | Not with NOSAFER on the command line | 10:39.20 |
| kens | Yes, sorry, I thought that was a separate question | 10:39.41 |
| rnissl | i'll be away for lunch -- need to talk about that later | 10:40.06 |
| kens | OK for me putting the -c....-f inside the @file works. I'm inclined to document this under both -c and @file as a limitation; if you want to use both of these then the -c...-f sequence must be in the @file | 10:43.12 |
| | More generally we probably need to point out in the -c code that this will (obviously) start the PostScript itnerpreter, which may limit what can be done afterwards in terms of -d and -s switches, and (unless -dNOSAFER is set) will freeze the file permissions | 10:44.59 |
| chrisl | http://git.ghostscript.com/?p=user/chrisl/ghostpdl.git;a=commitdiff;h=8e54a18822cac35f0f5229636dee241ae29d5d99 | 10:45.36 |
| kens | Hmm, what about files inside teh @file ? Will those input files run ? | 10:46.24 |
| chrisl | Yes | 10:46.34 |
| kens | You might do better to ask Robin to review that than me, but it 'looks' OK to my limited understanding | 10:46.47 |
| chrisl | Or, um, probably.... | 10:46.57 |
| | Do we allow @files inside @files ? | 10:47.17 |
| kens | Not that I know of, and I don't think we should! | 10:47.38 |
| chrisl | I'm fairly sure that would still work, but not 100% | 10:48.03 |
| kens | I will try it | 10:48.37 |
| | Well apparenlty @file inside @file works :-( | 10:50.56 |
| chrisl | Well, it also works with that patch, so that's okay | 10:52.48 |
| kens | OK well that sounds like a good solution then | 10:54.28 |
| chrisl | kens: The effect of -c is already mentioned in Use.htm | 10:57.45 |
| kens | OK good enough then :-) | 10:57.59 |
| rnissl | back from lunch ;-) | 11:23.00 |
| | so rc3 will fix that regression? | 11:23.09 |
| chrisl | rnissl: If we do an RC3 - it will definitely work in the release | 11:27.09 |
| rnissl | chrisl, then I'll pull and build a binary myself to finish testing. | 11:35.23 |
| | Thanks for your support. Bye. | 11:35.29 |
| chrisl | Thanks for reporting! | 11:35.36 |
| | <<<Back 1 day (to 2019/09/16) | Forward 1 day (to 2019/09/18)>>> | |
Log of #ghostscript at irc.freenode.net.