I am trying to collect the vendor of an executable file under differents UNIX-LIKE systems ( Red Hat, AIX, Solaris, Oracle Linux ...).
I would like to do the same as the following command on Windows :
WMIC /LOCALE:MS_409 DATAFILE WHERE (Name="C:\\Program Files\\Java\\jdk-10\\bin\\java.exe") GET manufacturer
I have looked at the file and strings command without success.
No clue how to achieve it.
Any help will be appreciated.
As pointed out UNIX files do not have a vendor, mostly because there is no standard for it, but RPM-based distributions like Red Hat provide a "vendor" that can be queried with a command like this:
rpm -qa --queryformat '%{NAME}TAB%{DISTRIBUTION}TAB%{VENDOR}\n'
(Use a TAB character for TAB in the code above if you want to load it into a spreadsheet program or similar)
rpmkeys --querytags lists all known query tags like NAME.
Related
We are migrating a bunch of COBOL programs from z/OS to AIX 7. We are using the IBM COBOL Compiler (5.1) on AIX. Now I don't understand how the file access and the file system work for COBOL on AIX.
The COBOL code is straight forward with
SELECT :FILE: ASSIGN TO :FILE:
ORGANIZATION IS SEQUENTIAL
ACCESS MODE IS SEQUENTIAL
STATUS IS S-STATUS.
and then doing an OPEN INPUT
This compiled fine on AIX:
PP 5724-Z87 IBM COBOL for AIX 5.1.0 in progress ...
LineID Message code Message text
91 IGYGR1216-I A "RECORDING MODE" of "F" was assumed for file
"CUSTOMERS".
94 IGYGR1216-I A "RECORDING MODE" of "F" was assumed for file
"LIST1".
97 IGYGR1216-I A "RECORDING MODE" of "F" was assumed for file "UINPUT".
Messages Total Informational Warning Error Severe Terminating
Printed: 3 3
End of compilation 1, program xxxxx, highest severity: Informational.
Now the problem is, that when running the program the file is not found. It gives Status code: 37
I know that I have to provide a file system for the file on the shell (ksh), as such:
export CUSTOMERS="STL-CUSTOMERS". The file is in the same directory as the program.
My question is this: Which file system to use? I tried "STL" which seemed to me like the "standard" AIX file system (which is JFS2). But that doesn't work. The other option are (from the COBOL on AIX Programming Guide 5.1):
DB2
SdU (SMARTdata Utilities)
SFS (Encina Structured File Server)
STL (standard language)
QSAM (queued sequential access method)
RSD (record sequential delimited)
We tried all and the file system that worked was "QSAM". The file is a text file (ASCII), that was transfered from the mainframe. But not directly, it was first copied by FTP and then converted to ASCII on Windows (we had to fix the line breaks). When playing around with it to make it work, we edited the file with vi to make the lines 80 characters each. So it was edited on AIX and looks like a ordinary text file on AIX.
Why would COBOL still want QSAM as "file system"? What does the term "file system" mean here any way? It seems that it is not in the sense of a real file system such as JFS.
I can see where this would be confusing... Especially coming from a Non-POSIX environment.
I'll start with the answer, and then provide more information.
For a normal text file, you want RSD, and to make sure that the \n is column 81.
A record length of 80 is just the data portion, not including the delimiter.
QSAM (fixed length) would appear to work, but would return the \n as part of the data!
Your FS=37 means that the attributes of the file don't match what the program is asking for (more esoteric than, say, FS=39 - invalid fixed attributes). In this case, it means the file you wanted to open was not, really, a STL file.
By filesystem we mean how the data is physically stored on the platter, SSD, RAM, ... More accurately, how we format the record before handing it off to the next lower level of I/O.
There are two basic types of filesystems:
Native (on top of JFS2, JFS, NFS, CIFS, ...) RSD, QSAM, LSQ, STL, SdU. These filesystems can be operated on by standard OS utilities
Non-Native (on top of another product) DB2 (DB2) and SFS (TxSeries/CICS). These filesystems are invisible to standard OS utilities
Then, there are groupings by type of COBOL organization (preferred):
Sequential: All filesystems support Sequential...z/OS: QSAM, VSAM
Relative: STL, SdU, SFS, DB2...........z/OS: VSAM
Indexed: STL, SdU, SFS, DB2...........z/OS: VSAM
Of the Native filesystems, QSAM(variable), STL and SDU contain metadata, making them not really viewable in vi,cat,... Ok... you can open them in vi, but it will look like utter garbage.
QSAM is a faithful implementation of z/OS:
Fixed length records: Raw data, no BDW/RDW, no line delimiters (\n).
Variable length records: RDW + raw data (no \n)... However there is no BDW.
RSD is a normal stream (text) file; each record is terminated with \n, which is not counted in the record length (the program will never see them).
LSQ (Line Sequential) is the same as on z/OS - messy semantics.
VSAM is an alias for a filesystem that provides all the features of z/OS VSAM.
Unfortunately, for historical reasons, it points to SdU...
STL is, by far and away, better at everything than is SdU.
SdU was the first filesystem to cover QSAM and VSAM, but is old and decrepit, compared to STL.
I'd like to find linux analogs of EnumDisplayDevices and EnumDisplaySettingsEx WinAPI functions.
The info I need to get is display name and state (if it active or not), width, height, bits per pixel and frequency.
How can I get this info using C (C++)?
Thanks.
As mentioned by 'Some programmer dude' in the comments you can have to go through the X window system. Most specifically one option would be the RandR protocol. Here is the protocol specification as well as the source code of the command xrandr that invokes the XRR functions and outputs most of the info that you want on the terminal. Look for the place where the
XRRScreenResources *res
is populated and then how the modes are fetched from it using the find_mode() function.
other commands that might assist you and don't go over the RandR extensions could be xprop(1), xdpyinfo(1), xwininfo(1)
Some programmer dude and ramrunner are absolutely correct. For most Linux systems, the graphical "desktop" is based on X Windows. Command-line tools for querying your X "display" include xrandr and xdpyinfo. The C-language source code for both are freely available; you can find many example programs with a Google search.
... HOWEVER ...
X Windows is "client/server". Your Linux "desktop" need not be on your physical PC; your X "display" could just as easily be a Windows desktop. In this case - xrandr and xdpyinfo are still applicable: they refer to where you're displaying (e.g. an XMing client on Windows), and not the physical host Linux is running on.
If you want to query the graphics devicews on your physical server ... then you'll instead use commands like lshw -c display or get-edid
I wanted to debug printf function, so when I step inside the printf function (gdb debugger) it showed me this:
__printf (format=0x80484d0 " my name is Adam") at printf.c:28
28 printf.c: No such file or directory.
What is the meaning of this?
And when I again started step then there are a lot more statements like this.
Please help me to understand this.
I think it's pretty clear. There is a place where the gdb expects the source code to be, so download glibc's source code and put it there. I think the error message contains the full path.
If it's a linux distro it's fairly simple in fact because usually source packages are shipped too. Otherwise you need to find the source code yourself, note that it MUST be exactly the same that was used to compile the c library components, not just the same version because distributors often make changes to the sources.
Well, for the debugger to show you the code that was compiled into the binaries you're using, you need the original code somewhere.
You don't seem to have that, so your debugger can't find it.
Notice that you usually do not want to debug the source code of your std library functions, but only the way they are being called. For that, the usual "debug symbol" packages of your operating systems are optimal.
As others have answered, GDB was unable to find the source file.
For the C runtime libraries, Linux distributions may provide a debuginfo RPM that you can install, which may allow GDB to view the files. For example:
$ yum search glibc-debuginfo
...
glibc-debuginfo.x86_64 : Debug information for package glibc
glibc-debuginfo-common.x86_64 : Debug information for package glibc
...
The glibc package and the glibc-debuginfo are a matched pair. There is no explicit dependency, but glibc-debuginfo package won't work unless it is matched with the same version of glibc.
If you have the sources unpacked somewhere, but not where GDB is expecting them to be, you can attempt to use either the directory or the set substitute-path command to let GDB know where the sources are.
The directory command tells GDB to prepend a prefix ahead of any source file path it is attempting to find. For example, if the source tree is actually located under the /tmp, you could use:
(gdb) directory /tmp
The set substitute-path command is used to tell GDB to replace a matching prefix in a source file path with a different path prefix. For example, if the compiled source file was in /build/path/source.c, but in debugging the source file is actually in /usr/home/alice/release-1.1/source.c, then you could use:
(gdb) set substitute-path /build/path /usr/home/alice/release-1.1
The command assumes that you are only specifying a complete path names, so it won't perform the substitution on /build/pathological/source.c.
Using IAR IDE for building ARM executables from C source, I can see the disassembly, including labels, addresses, opcode and instructions in the relevant window.
I am trying to dump the contents of a range of addresses to a text file, but can't find a way to do that. The window text is not selectable so I cannot use copy/paste. There is no menu associated that enables this.
As an alternative, I can generate the list and assembly files, but these seem to be limited to my code, and do not contain the CRT code or any ROM sections, which I am interested in.
Any way to dump a selected address range?
You want to use ielfdumparm located in your Workbench directory under arm/bin. Here's the help for the tool.
Usage: IElfDump input_file [output_file]
Available command line options:
--all Dump all sections
--code Dump only code sections
--no_header Do not produce a list header
--no_rel_sections
Do not output associated .rel sections
--no_strtab Do not include strtab sections
--output file
-o file Name of text file to create
--raw Use raw text format
--section #|name[,...]
-s #|name[,...] Dump only section(s) with given numbers/names
--source Include source in disassembled code in executables
--use_full_std_template_names
Don't use short names for standard C++ templates
-a All sections, except strtab sections
-f file Read command line options from file
To get a similar output to the debug view, I would suggest --code to avoid dumping your data space, and --source to have it embed your original C woven in with the assembly.
You can specify sections, but it doesn't look like you can specify address range. You may be able to pair this with some of the other ELF tools to extract just a specific address range, and then run this tool on that. Alternatively, this dumps in address order so you could dump the entire ELF file and then just look at the address range you want after the fact.
I use Snagit to capture text that is not selectable.
Snagit is a screen snapshot tool (a very good one). Besides making classic screen shots it supports to capture text and save it as ASCII text. It can also automatically scroll windows to capture long texts.
Maybe it is worth a try. There is a 30-day trial version available.
Compiling on the shared CentOS server is not allowed. Therefore, I compile my program in my Debian computer, linking it with Debian's system libraries such as libc, etc. Then I upload my program and the Debian system libraries and my program works. The only problem is that setlocale() does not work at CentOS. CentOS has "en_US.utf8" installed and works on all programs except mine. I suspect that I have to also upload Debian's locale files ? How could I link my program to the Debian locale files ? I tried to use LOCPATH but I am unsure of how it works exactly. Which files do I have to link to and how ?
C program:
setenv("LOCPATH", "/", 1);
if (setlocale(LC_ALL, "en_US.utf8") == NULL) {
puts("not set");
}
I used a hex editor to modify the path to /usr/lib/locale/locale-archive which apparently is the only file that setlocale() uses according to strace. This method is dirty but it worked.
According to man LOCPATH, this environment variable is non-standard, so its use is not recommended. No examples are given anywhere of how to use it nor what is meant exactly by a path to "locale's object files".
I guess the only real way of modifying the path is a glibc modification and recompilation.
Quote: LOCPATH is an environment variable that tells the setlocale() function the name of the directory from which to load locale object files. If LOCPATH is not defined, the default directory /usr/lib/nls/locale is searched. LOCPATH is similar to the PATH environment variable; it contains a list of z/OS UNIX directories separated by colons.
So just specifying / and hoping that it does a recursive search will not work.
You could also produce a static binary and upload that to the host.