> Am 10.03.2021 um 16:29 schrieb Brian Andrus <toomuc...@gmail.com>: > > Marcus is right here. Filtering the input so you don't have GIGO is on the > admin. > > There are too many different languages/characters to expect that to be > handled by slurm and would make it bulkier for most users with no benefit.
Well, yes. I can see the point. The longterm solution might be to exclude characters 0x00–0x1F and/or allow only printable UTF-8 characters with proper spacing in `squeue` and alike, as some characters take 2 or more bytes. for their representation. -- Reuti > Wrapper scripts and job_submit.lua are definitely your friends. > > Brian Andrus > > On 3/10/2021 5:05 AM, Marcus Boden wrote: >> Yeah, I wondered something like that too, as it makes some of my scripts >> quite fragile. I just tried your name on a test system and now calling >> squeue paints my cli yellow :D >> >> You could write a job_submit plugin to catch 'malicious' input, but so far >> no user ever did something like that on our system, so I don't think that's >> necessary. >> >> Best, >> Marcus >> >> On 10.03.21 12:06, Reuti wrote: >>> >>>> Am 09.03.2021 um 13:37 schrieb Marcus Boden <mbo...@gwdg.de>: >>>> >>>> Then I have good news for you! There is the --delimiter option: >>>> https://slurm.schedmd.com/sacct.html#OPT_delimiter= >>> >>> Aha, perfect – thx. Maybe it should be noted in the man page for the >>> "-p"/"-P". >>> >>> But this leads to another question: there is no well defined character set >>> for allowed job names, and I can have a job: >>> >>> $ sbatch --job-name="fu"$'\007'$'\033[32m'"bar" slurm-job.sh >>> >>> which might make some noise when using `squeue` and messes up the output? >>> >>> -- Reuti >>> >>> >>>> Best, >>>> Marcus >>>> >>>> On 09.03.21 12:10, Reuti wrote: >>>>> Hi: >>>>>> Am 09.03.2021 um 08:19 schrieb Bjørn-Helge Mevik <b.h.me...@usit.uio.no>: >>>>>> >>>>>> "xiaojingh...@163.com" <xiaojingh...@163.com> writes: >>>>>> >>>>>>> I am doing a parsing job on slurm fields. Sometimes when one field is >>>>>>> too long, slum will limit the length with a “+”. >>>>>> >>>>>> You don't say which slurm command you are trying to parse the output >>>>>> from, but if it is sacctmgr, it has an option --parsable2(*) >>>>>> specifically designed for parsing output, and which does not truncate >>>>>> long field values. >>>>>> >>>>>> (*) There is also --parsable, but that puts an extra "|" at the end of >>>>>> the line, so I prefer --parsable2. >>>>> It would even be better to have the option to use an argument for these >>>>> two options or even --parsable='`\000' like in `tr`. For now users can >>>>> use "|" in jobname, account or comment which might break any parsing. >>>>> -- Reuti >>>>>> -- >>>>>> Cheers, >>>>>> Bjørn-Helge Mevik, dr. scient, >>>>>> Department for Research Computing, University of Oslo >>>>>> >>>> >>>> -- >>>> Marcus Vincent Boden, M.Sc. >>>> Arbeitsgruppe eScience, HPC-Team >>>> Tel.: +49 (0)551 201-2191, E-Mail: mbo...@gwdg.de >>>> ------------------------------------------------------------------------- >>>> Gesellschaft für wissenschaftliche Datenverarbeitung mbH Göttingen (GWDG) >>>> Am Faßberg 11, 37077 Göttingen, URL: https://www.gwdg.de >>>> >>>> Support: Tel.: +49 551 201-1523, URL: https://www.gwdg.de/support >>>> Sekretariat: Tel.: +49 551 201-1510, Fax: -2150, E-Mail: g...@gwdg.de >>>> >>>> Geschäftsführer: Prof. Dr. Ramin Yahyapour >>>> Aufsichtsratsvorsitzender: Prof. Dr. Norbert Lossau >>>> Sitz der Gesellschaft: Göttingen >>>> Registergericht: Göttingen, Handelsregister-Nr. B 598 >>>> >>>> Zertifiziert nach ISO 9001 >>>> ------------------------------------------------------------------------- >>>> >>> >>> >> >
