I have a strange (don't ask) need to see a few examples of a Win XP cmd shell DIR command for lots (some) of different localized versions of windows (eg. French, Spanish, etc).
The specific command I need is (note that this command is important... if you don't bother to use this command then don't bother to respond):
dir /4 /-c /t:a /n /a:-d-h-s
I know it's a crazy hope but I'm hoping to be able to chop/parse the output regardless of localization.
Probably not what you want to hear but we found all sorts of problems in relying on behavior in different localizations of Windows.
We had a cmd file which worked fine in US English but when we sent it for localization, they found all sorts of issues, and we have to support about 23 different versions.
In the end, it was easier to write (actual C) code to get the information via Win32 and output it in the format we wanted. This removed reliance on specific localization formats and configuration issues (some commands output differently not just based on locale but also on user configuration).
My advice: find a different way of doing this.
Polish windows Vista outputs:
C:\Users\Karol>dir /4 /-c /t:a /n /a:-d-h-s
Wolumin w stacji C to OS
Numer seryjny woluminu: 3EC1-6B83
Katalog: C:\Users\Karol
2009-12-10 21:19 2263 intlname.ols
2009-07-23 21:17 1480 laptop_to_epia.ppk
2009-07-23 21:17 466 laptop_to_epia.pub
2010-01-31 09:49 10392 _viminfo
4 plik(ów) 14601 bajtów
0 katalog(ów) 10880864256 bajtów wolnych
Here's the output for Korean XP:
C µå¶óÀ̺êÀÇ º¼·ý¿¡´Â À̸§ÀÌ ¾ø½À´Ï´Ù.
º¼·ý ÀÏ·Ã ¹øÈ£: 7C33-7DCE
C:\WINDOWS\system32 µð·ºÅ͸®
2009-02-02 ¿ÀÈÄ 11:39 1697 $winnt$.inf
2008-02-19 ¿ÀÈÄ 09:07 2151 12520437.cpx
2008-02-19 ¿ÀÈÄ 09:07 2233 12520850.cpx
2008-02-19 ¿ÀÈÄ 09:06 100352 6to4svc.dll
2008-02-19 ¿ÀÈÄ 08:47 1460 a15.tbl
(seem to have lost the unicode during transfer... but for my purposes that's ok).
Sure... it's the wrong way... but needs must/devil drives. The underlying problem is that the machine the command runs on cannot be modified/relied upon. The parsing/chopping is pretty minor (pull out a filename, file size and the creation date). The good news is that the filename is guaranteed to not include any spaces. Which means the last 2 fields of a split() are the filename and size and the first N fields are the date (note I don't need the date as a date, just a string is fine). Trickiness may be involve ensuring unicode moves around correctly (unlike in the Korean example).
Related
I had some difficulty posing my problem in a way that the Title filter found pleasing. The real problem is that modifying only the GhostPDF.PDD file in the GS9.26 installation in Windows 10 doesn't seem to affect the output after a re-installation using Windows 10 Device Installer.
I print to a networked Sun SPARCprinter 1 which is controlled by Ghostprint (script?) compiled to run on SunOS 4.1.4. This has worked successfully for some years printing output from Windows XP using Adobe's PS driver and a SPARCstation PPD cobbled together from samples found on the net.
I've installed Artifex's 9.26 on Windows 10 and output to an LPR printer (The Sun). The output works, is recognized as PS output by the Sun, but produces a number of FATAL errors.
I need to edit the Windows Ghostscript installation to output PS files which are more suitable for the Sun.
So to my simple question: Do I need to modify anything in the Ghostscript Windows 10 installation other than the Ghostpdf.PPD file?
additional info:
SPARCstation 10 information:
SunOS 4.1.4
arcad# gcc -dumpversion
2.95.2 Note: I had to bootstrap this version up from the early GCC which could be compiled with the SunOS 4.1.4 C compiler. I had the impression I couldn't bring it up any further but could be mistaken.
arcad# gs --help
Aladdin Ghostscript 6.01 (2000-03-17)
Copyright (C) 2000 Aladdin Enterprises ...
Usage: gs [switches] [file1.ps file2.ps ...]
Most frequently used switches: (you can use # in place of =)
-dNOPAUSE no pause after page | -q `quiet', fewer messages
-g<width>x<height> page size in pixels | -r<res> pixels/inch resolution
-sDEVICE=<devname> select device | -dBATCH exit after last file
-sOutputFile=<file> select output file: - for stdout, |command for pipe,
embed %d or %ld for page #
Input formats: PostScript PostScriptLevel1 PostScriptLevel2 PDF
.....
For more information, see /usr/local/share/ghostscript/6.01/doc/Use.htm.
Note: I think this is the most recent GS version I can compile with this gcc version
printcap section:
gp|GhostPrinter:\
:lp=/dev/lpvi0:sd=/var/spool/gsprintspool:lf=/var/spool/gsprintspool/log:\
:mx#0:sh:if=/usr/local/libexec/lpfilter-gps:
Typical spool file - "....." indicates stuff not included here"
arcad# more dfA004DESKTOP-M8C5I86
%!PS-Adobe-3.0
%%Title: Document
%%Creator: PScript5.dll Version 5.2.2
%%CreationDate: 12/14/2018 19:56:8
%%For: jferg
%%BoundingBox: (atend)
%%Pages: (atend)
%%Orientation: Portrait
%%PageOrder: Special
%%DocumentNeededResources: (atend)
%%DocumentSuppliedResources: (atend)
%%DocumentData: Clean7Bit
%%TargetDevice: (Ghostscript) (3010) 815
%%LanguageLevel: 3
%%EndComments
%%BeginDefaults
%%PageBoundingBox: 0 0 612 792
%%ViewingOrientation: 1 0 0 1
%%EndDefaults
.....
%%EndResource
userdict /Pscript_WinNT_Incr 230 dict dup begin put
%%BeginResource: file Pscript_FatalError 5.0 0
userdict begin/FatalErrorIf{{initgraphics findfont 1 index 0 eq{exch pop}{dup
length dict begin{1 index/FID ne{def}{pop pop}ifelse}forall/Encoding
{ISOLatin1Encoding}stopped{StandardEncoding}if def currentdict end
/ErrFont-Latin1 exch definefont}ifelse exch scalefont setfont counttomark 3 div
cvi{moveto show}repeat showpage quit}{cleartomark}ifelse}bind def end
%%EndResource
userdict begin/PrtVMMsg{vmstatus exch sub exch pop gt{[
quires more memory than is available in this printer.)100 500
more of the following, and then print again:)100 485
put format, choose Optimize For Portability.)115 470
ce Settings page, make sure the Available PostScript Memory is accur--More--(2%)
ce the number of fonts in the document.)115 440
ocument in parts.)115 425 12/Times-Roman showpage
Error: Low Printer VM ]%%)= true FatalErrorIf}if}bind def end
2016 ge{/VM?{pop}bind def}{/VM? userdict/PrtVMMsg get def}ifelse
.....
SPARCprinter PDD file which works with Adobe PS in Windows XP:
john#hp2:~/sun-stuff/cups-sparc$ more SPARCprinter2.ppd
*PPD-Adobe: "4.1"
*% PostScript(R) Printer Description File for SPARCprinter
*% Date: 94/01/14
*% Copyright 1994 Sun Microsystems, Inc. All Rights Reserved.
*% Permission is granted for redistribution of this file as
*% long as this copyright notice is intact and the contents
*% of the file is not altered in any way from its original form.
*% End of Copyright statement
*% Changed margins on SPARCprinter JAF 3-3-2017
*FormatVersion: "4.1"
*FileVersion: "1.10"
*LanguageEncoding: ISOLatin1
*LanguageVersion: English
*PCFileName: "SPRN.PPD"
*Product: "(SPARCprinter)"
*PSVersion: "(3.000) 0"
*ModelName: "SPARCprinter"
*ShortNickName: "SPARCprinter"
*NickName: "SPARCprinter"
*% ==== Device Capabilities ===============
*LanguageLevel: "3"
*Extensions: CMYK Composite
*FreeVM: "4194304"
*ColorDevice: False
*DefaultColorSpace: Gray
*VariablePaperSize: False
*TTRasterizer: None
*FileSystem: False
..... more of the usual stuff
I don't really understand why you have installed Ghostscript on Windows. Windows is perfectly capable of producing PostScript files all of its own. In addition, the PPD file doesn't actually do very much, it is simply a text file with descriptions of the capabilities of the printer.
So the real problem is, or seems to be, that your SUN setup doesn't like the PostScript being produced by the new version of Windows.
You don't say how you are printing the PostScript file. not how your printer is 'controlled by Ghostscript' (I'm not aware of any product called Ghostprint, there is a GSPrint as part of GSView, but that's really for Windows).
Assuming you are using Ghostscript on your Sparc workstation to drive the pritner, then the most likely problem I would say is that you are using an old version of Ghostscript on the workstation, and it doesn't like the PostScript being generated by the newer version of Windows.
If you had included the transcript from the workstation Ghostscript installation it might be possible to say more but without that I'm rather guessing.
Another possibility is that you are using the ps2write device in Ghostscript to produce PostScript files on Windows. I can't think why you would be doing that, but it sort of fits your description. In that case editing the PPD file will have no effect, because Ghostscript doesn't use it.
Now the ps2write device emits level 2 PostScript, the clue is in the name, and its possible again that your Sparc setup is so elderly that it doesn't understand level 2, or doesn't fully implement it. In which case you will probably get errors. Again, if you were to provide the text of the error messages this would help!
In the latter case, you are frankly out of luck. We dropped support for level 1 PostScript output some time ago, what with level 2 being 28 years old now and level 3 coming up on 20. If you need language level 1 output you will have to go back to a very old version of Ghostscript. Something like 9.07 (from 5 and a half years ago) was the last version that included the pswrite device.
With effort you could take the pswrite device and upgrade it so that it works with the current version of Ghostscript
[EDIT]
My word, that's a really old version of Ghostscript!
You could try building a new version to replace it, but I also don't know if current code will compile on gcc 2.95. It 'should' because we only expect C89, but the third party libraries (which are essential) may very well not compile.
The PostScript file you quoted has been produced by Windows, not by Ghostscript (%%Creator: PScript5.dll Version 5.2.2). So it seems likely to me that your problem is the PostScript being produced by the newer version of Windows doesn't work with your 18 year old version of Ghostscript. That's not actually entirely surprising.
If you look at the DSC comments it says:
%%LanguageLevel: 3
And your Ghostscript information says that it supports language levels 1 and 2. At the time the level 3 spec had only just been published (1999), and clearly the maintainers back then hadn't had time to fully implement it.
Note that the ghostpdf.ppd file is intended for use with Ghostscript as a 'print to PDF' printer along with the RedMon port monitor.
Now its not obvious to me which PPD file you are using, but..... Both the ghostpdf.ppd file and the sparcprinter ppd file have :
*LanguageLevel: "3"
That tells the PostScript driver that it can use language level 3, which your Sparc Ghostscript doesn't support. You could try changing that to:
*LanguageLevel: "2"
and see if that makes a difference (you will have to uninstall the printers from Windows and re-install them with the modified PPD file).
If it doesn't work, the only other thing I can think of is to use the Ghostscript you installed on the Windows system, and preprocess the PostScript file produced by Windows before you send it on. You can use the ps2write device in Ghostscript 9.26 to take in the level 3 file, and produce a level 2 file. It might be a bit bigger, but it ought to work.
To do that on Windows you would use something like:
gswin64c -sDEVICE=ps2write -sOutputFile=out.ps <input.ps>
The file 'out.ps' should then be a level 2 PostScript file. I can't guarantee that the output will then work the old version of Ghostscript on your Sparc, but you stand a chance!
On Windows 7 cmd.exe, the perl6-debug-m script outputs ansi escape sequences to set the colors, I suppose. How do I suppress these codes or at least make them functional? I'm just getting started with Perl 6 after working with Perl 4 and Perl 5 for over 20 years. I need this to work on Windows because of a program I'm trying to port from Perl 5.
C:\rakudo\bin\lib>perl6 -v
This is Rakudo Star version 2018.04.1 built on MoarVM version 2018.04.1
implementing Perl 6.c.
C:\rakudo\bin\lib>perl6-debug-m
←[35m>>> LOADING ←[0m<REPL 1>
←[34m+ <REPL 1> (1 - 1)←[0m
←[34m| ←[0m←[1;33mREPL←[0m
←[34m> ←[0mquit
←[34m- ←[0mRun END blocks (y/N)?
C:\rakudo\bin\lib>perl6 -V |grep -v "moar:"
distro::auth=unknown
distro::desc=2018-05-20T09:17:12.587605-04:00
distro::is-win=True
distro::name=mswin32
distro::path-sep=;
distro::release=unknown
distro::signature=
distro::version=6.3
kernel::arch=unknown
kernel::archname=unknown-win32
kernel::auth=unknown
kernel::bits=64
kernel::desc=
kernel::hardware=unknown
kernel::name=win32
kernel::release=unknown
kernel::signature=
kernel::version=unknown
perl6::build-date=2018-05-07T10:08:20Z
perl6::codename=
perl6::implementation=Rakudo Star
perl6::language_version=6.c
perl6::libdir=C:\rakudo\share
perl6::prefix=C:\rakudo
perl6::release-number=
perl6::source-digest=688d0872d150048d083b7a499e9fc7a9e8b6ab5b
perl6::version=2018.04.1
repo::chain=inst#C:\Users\danhale\.perl6 inst#C:\rakudo\share\perl6\site inst#C:\rakudo\share\perl6\vendor inst#C:\rakudo\share\perl6 ap# nqp# perl5#
There's currently no way to disable them (I just checked the debugger interface's source to verify that). I've previously used ANSICON on Windows in order to work with applications that produce ANSI color codes, including the Perl 6 debugger, and recall that it rendered them fine.
Can anyone tell me what the meaning of the value for st_ino is when running os.stat() on Windows (Python 3.5.3)?
In earlier Python releases, this contained dummy values, but this has recently changed and I couldn't find how it is calculated/generated. I suspect that it differs based on the file system (NTFS, FAT, ...)
Example
import os
stat = os.stat(r'C:\temp\dummy.pdf')
for attr in dir(stat):
if attr.startswith('st_'):
print('{}: {}'.format(attr,
stat.__getattribute__(attr)))
Result
st_atime: 1495113452.7421005
st_atime_ns: 1495113452742100400
st_ctime: 1495113452.7421005
st_ctime_ns: 1495113452742100400
st_dev: 2387022088
st_file_attributes: 33
st_gid: 0
st_ino: 10414574138828642
st_mode: 33060
st_mtime: 1494487966.9528062
st_mtime_ns: 1494487966952806300
st_nlink: 1
st_size: 34538
st_uid: 0
Background
I used the shutil.copyfile() function an ran into an SameFileError. After looking through the code (and despite what it says in the comments of shutil.py) the shutil._samefile() function does not compare pathnames in Windows. Instead, it uses os.path.samefile() which compares the st_ino and st_dev values.
Both source and target file resided on the same device (volume), which would explain why the value for st_dev was the identical. But I'm still puzzled as to why st_ino had the same value for both files.
Remark: both files were on a Sharepoint volume mounted using webDAV, so their st_ino value may have been 0 (dummy), which would explain why they were equal. I'm still curious though ;-)
Update
As I suspected, the value for st_ino returned for the files residing on the Sharepoint volume (WebDAV), was 0, as was the value for st_dev. This is the reason for (incorrect) SameFileError. Example output:
\\sharepoint#SSL\AUT.pdf os.stat_result(st_mode=33206, st_ino=0, st_dev=0, st_nlink=1, st_uid=0, st_gid=0, st_size=4717, st_atime=1495031011, st_mtime=1495031011, st_ctime=1495031570)
\\sharepoint#SSL\ING.pdf os.stat_result(st_mode=33206, st_ino=0, st_dev=0, st_nlink=1, st_uid=0, st_gid=0, st_size=4722, st_atime=1495031203, st_mtime=1495031203, st_ctime=1495031733)
\\sharepoint#SSL\WAG.pdf os.stat_result(st_mode=33206, st_ino=0, st_dev=0, st_nlink=1, st_uid=0, st_gid=0, st_size=4710, st_atime=1495031511, st_mtime=1495031511, st_ctime=1495031912)
Bash-on-Ubuntu-on-Windows supports case-sensitive file paths. This means that I can create two files or directories with names only differing in capitalization. I have issues accessing those files, though.
Running
bash -c "touch Magic ; mkdir magic ; echo Secret! > magic/secret"
Creates a file names Magic, a directory named magic and a file names secret in that directory.
bash -c "ls -lR" yields
.:
total 0
drwxrwxrwx 2 root root 0 Aug 23 10:37 magic
-rwxrwxrwx 1 root root 0 Aug 23 10:37 Magic
./magic:
total 0
-rwxrwxrwx 1 root root 8 Aug 23 10:37 secret
(I am not sure why I get root, as it is not the default user, but that does not seem relevant to my question.)
Windows Explorer shows:
Now, while bash can easily access the magic/secret file in the directory, Windows seems to treat both the directory and the file as one and the same. So double-clicking the directory I get a "directory name invalid" error
Same goes for using cd, as I get The directory name is invalid. printed out.
Are there any APIs that allow me to access those case-sensitive paths, or create them? It seems that regular Windows APIs ignore character case completely when accessing existing files.
Case-sensitive paths can be used on Windows with NTFS, but it requires a bit of extra work.
First, case-sensitivity must be enabled system-wide. This is done by setting the HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel\ dword:ObCaseInsensitive registry value to 0, then restarting the system.
I found this part here.
Once case-sensitivity is enabled, it is possible to use CreateFile to with case-sensitive paths. To do that, you have to pass the FILE_FLAG_POSIX_SEMANTICS as part of the dwFlagsAndAttributes parameter. From msdn:
Access will occur according to POSIX rules. This includes allowing multiple files with names, differing only in case, for file systems that support that naming.
I found this part in this answer.
By setting the registry setting and the CreateFile flag, I was able to access case-sensitive paths.
I have Ant configured to use the AnsiColorLogger. In Mac OS 10.5, everything was fine. Since upgrading to Snow Leopard, the AnsiColorLoggger no longer works. I see the Ant output (uncolorized) for a second then it just disappears. Has anyone else gotten this working in Snow Leopard? Other ANSI colors are working fine in Terminal.app (colored ls output, colors in my prompt).
Also, would this be a better question on SuperUser?
UPDATE: I have sorted out the issue. It has to do with ANT giving escape sequences that while appropriate for a linux xterm, are NOT correctly interpreted by Mac OS X. It is possible to filter the ANT output to convert these sequences and restore colorized output.
The moral of the story is that this wrapper script will achieve colorized output:
# cat /workspace/SDK/bin/ant-wrapper.sh
/usr/bin/ant -logger org.apache.tools.ant.listener.AnsiColorLogger "$#" | perl -pe 's/(?<=\e\[)2;//g'
# alias ant='/workspace/SDK/bin/ant-wrapper.sh'
# ant publish
(output has lots of pretty colors; well, maybe not so pretty, more like an easter egg)
Original Post (and debugging steps):
I'm having similar issues with regard to AnsiColorLogger not displaying colors at all. I'm not sure what the author means by "[output appears] for a second then it just disappears". That seems like a strange problem to occur on the Terminal.
My Box:
# uname -a
Darwin Dave-Dopsons-MacBook-Pro.local 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
This is the ANT Logger we are using:
http://ant.apache.org/manual/listeners.html#AnsiColorLogger
Here's a related forum post (tried the advice given, to no avail): http://ant.1045680.n5.nabble.com/Macosx-and-AnsiColorLogger-td1355310.html
I did "ant | less", and I DO see escape sequences, but still no colors:
Buildfile: /workspace/Words/words_blackberry/build.xml
ESC[2;32m
publish:ESC[m
Still blocked on this, and would love advice if anyone has gotten it to work on OSX
GOT IT!
So here's the output of colorized ls:
# CLICOLOR_FORCE=exfxcxdxbxegedabagacad ls -lGF | less
total 112
-rw-r--r-- 1 ddopson admin 6511 May 29 12:41 build.xml
drwxr-xr-x 6 ddopson admin 204 May 28 23:59 ESC[34meclipse-binESC[mESC[m/
lrwxr-xr-x 1 ddopson admin 35 May 23 21:24 ESC[35mfilesESC[mESC[m# -> ../artwork/output/blackberry/files/
lrwxr-xr-x 1 ddopson admin 36 May 23 21:20 ESC[35mimagesESC[mESC[m# -> ../artwork/output/blackberry/images/
Notice how the escape sequences are subtly different; they don't have the '2;' like ANT did...
So to test this theory:
ant -logger org.apache.tools.ant.listener.AnsiColorLogger publish | sed 's/2;//g'
... and the output is COLORIZED! Victory!
I've take ddopson's knowledge and crammed it into a single line:
ant () { command ant -logger org.apache.tools.ant.listener.AnsiColorLogger "$#" | sed 's/2;//g' ; }
This works by using a Bash Function. Place this in your ~/.profile file and it will do the same thing as ddopson's ant-wrapper.sh, but without needing a second file to make it work. Slightly more elegant and less fragile.