GNU ar is designed to be compatible with two different facilities. You can control its activity using command-line options, like the different varieties of ar on Unix systems; or, if you specify the single command-line option [-M], you can control it with a script supplied via standard input, like the MRI "librarian" program.
When you use ar in the Unix style, ar insists on at least two arguments to execute: one keyletter specifying the operation (optionally accompanied by other keyletters specifying modifiers), and the archive name to act on.
Most operations can also accept further member arguments, specifying particular files to operate on.
d Delete modules from the archive. Specify the names of modules to be deleted as member ...; the archive is untouched if you specify no files to delete.
If no modifiers are used with m, any members you name in the member arguments are moved to the end of the archive; you can use the a, b, or i modifiers to move them to a specified place instead.
q Quick append; Historically, add the files member ...to the end of archive, without checking for replacement.
r Insert the files member ...into archive (with replacement). This operation differs from q in that any previously existing members are deleted if their names match those being added.
If one of the files named in member ...does not exist, ar displays an error message, and leaves undisturbed any existing members of the archive matching that name.
t Display a table listing the contents of archive, or those of the files listed in member ...that are present in the archive. Normally only the member name is shown; if you also want to see the modes (permissions), timestamp, owner, group, and size, you can request that by also specifying the v modifier.
u Normally, ar r ...inserts all files listed into the archive. If you would like to insert only those of the files you list that are newer than existing members of the same names, use this modifier. The u modifier is allowed only for the operation r (replace). In particular, the combination qu is not allowed, since checking the timestamps would lose any speed advantage from the operation q.
ar ignores an initial option spelt -X32_64, for compatibility with AIX. The behaviour produced by this option is the default for GNU ar. ar does not support any of the other -X options; in particular, it does not support [-X32] which is the default for AIX ar.
If you use the single command-line option -M with ar, you can control its operation with a rudimentary command language. This form of ar operates interactively if standard input is coming directly from a terminal. During interactive use, ar prompts for input (the prompt is AR >), and continues executing even after errors. If you redirect standard input to a script file, no prompts are issued, and ar abandons execution (with a nonzero exit code) on any error.
The ar command language is not designed to be equivalent to the command-line options; in fact, it provides somewhat less control over archives. The only purpose of the command language is to ease the transition to GNU ar for developers who already have scripts written for the MRI "librarian" program.
commands are recognized in upper or lower case; for example, LIST is the same as list. In the following descriptions, commands are shown in upper case for clarity.
a single command may appear on each line; it is the first word on the line.
empty lines are allowed, and have no effect.
comments are allowed; text after either of the characters * or ; is ignored.
Whenever you use a list of names as part of the argument to an ar command, you can separate the individual names with either commas or blanks. Commas are shown in the explanations below, for clarity.
+ is used as a line continuation character; if + appears at the end of a line, the text on the following line is considered part of the current command.
OPEN or CREATE specify a current archive, which is a temporary file required for most of the other commands.
SAVE commits the changes so far specified by the script. Prior to SAVE, commands affect only the temporary copy of the current archive.
Add all the contents of archive (or, if specified, each named module from archive) to the current archive.
Requires prior use of OPEN or CREATE.
Add each named member as a module in the current archive.
CLEAR Discard the contents of the current archive, canceling the effect of any operations since the last SAVE. May be executed (with no effect) even if no current archive is specified.
Creates an archive, and makes it the current archive (required for many other commands). The new archive is created with a temporary name; it is not actually saved as archive until you use SAVE. You can overwrite existing archives; similarly, the contents of any existing file named archive will not be destroyed until SAVE.
Delete each listed module from the current archive; equivalent to ar -d archive module ... module.
Output normally goes to the standard output stream; however, if you specify outputfile as a final argument, ar directs the output to that file.
END Exit from ar, with a 0 exit code to indicate successful completion. This command does not save the output file; if you have changed the current archive since the last SAVE command, those changes are lost.
Opens an existing archive for use as the current archive (required for many other commands). Any changes as the result of subsequent commands will not actually affect archive until you next use SAVE.
In the current archive, replace each existing module (named in the REPLACE arguments) from files in the current working directory. To execute this command without errors, both the file, and the module in the current archive, must exist.
SAVE Commit your changes to the current archive, and actually save it as a file with the name specified in the last CREATE or OPEN command.
GNU nm lists the symbols from object files objfile .... If no object files are listed as arguments, nm assumes the file a.out.
A The symbol's value is absolute, and will not be changed by further linking.
B The symbol is in the uninitialized data section (known as BSS).
C The symbol is common. Common symbols are uninitialized data. When linking, multiple common symbols may appear with the same name. If the symbol is defined anywhere, the common symbols are treated as undefined references. For more details on common symbols, see the discussion of --warn-common in Options,,Linker options,ld.info,The GNU linker.
D The symbol is in the initialized data section.
G The symbol is in an initialized data section for small objects. Some object file formats permit more efficient access to small data objects, such as a global int variable as opposed to a large global array.
I The symbol is an indirect reference to another symbol. This is a GNU extension to the a.out object file format which is rarely used.
N The symbol is a debugging symbol.
R The symbol is in a read only data section.
S The symbol is in an uninitialized data section for small objects.
T The symbol is in the text (code) section.
U The symbol is undefined.
V The symbol is a weak object. When a weak defined symbol is linked with a normal defined symbol, the normal defined symbol is used with no error. When a weak undefined symbol is linked and the symbol is not defined, the value of the weak symbol becomes zero with no error.
W The symbol is a weak symbol that has not been specifically tagged as a weak object symbol. When a weak defined symbol is linked with a normal defined symbol, the normal defined symbol is used with no error. When a weak undefined symbol is linked and the symbol is not defined, the value of the symbol is determined in a system-specific manner without error. On some systems, uppercase indicates that a default value has been specified.
- The symbol is a stabs symbol in an a.out object file. In this case, the next values printed are the stabs other field, the stabs desc field, and the stab type. Stabs symbols are used to hold debugging information. For more information, see Top,Stabs,Stabs Overview,stabs.info, The "stabs" debug format.
? The symbol type is unknown, or object file format specific.
-B The same as [--format=bsd] (for compatibility with the MIPS nm).
Decode ( demangle) low-level symbol names into user-level names. Besides removing any initial underscore prepended by the system, this makes C++ function names readable. Different compilers have different mangling styles. The optional demangling style argument can be used to choose an appropriate demangling style for your compiler.See Section "c++filt", for more information on demangling.
Use the output format format, which can be bsd, sysv, or posix. The default is bsd. Only the first character of format is significant; it can be either upper or lower case.
Print size, not the value, of defined symbols for the bsd output format.
Sort symbols by size. The size is computed as the difference between the value of the symbol and the value of the symbol with the next higher value. If the bsd output format is used the size of the symbol is printed, rather than the value, and -S must be used in order both size and value to be printed.
Specify an object code format other than your system's default format.See Section "Target Selection", for more information.
-X This option is ignored for compatibility with the AIX version of nm. It takes one parameter which must be the string [32_64]. The default mode of AIX nm corresponds to [-X 32], which is not supported by GNU nm.
objcopy creates temporary files to do its translations and deletes them afterward. objcopy uses bfd to do all its translation work; it has access to all the formats described in bfd and thus is able to recognize most formats without being told explicitly.See Section "BFD".
objcopy can be used to generate a raw binary file by using an output target of binary (e.g., use [-O binary]). When objcopy generates a raw binary file, it will essentially produce a memory dump of the contents of the input object file. All symbols and relocation information will be discarded. The memory dump will start at the load address of the lowest section copied into the output file.
When generating an S-record or a raw binary file, it may be helpful to use [-S] to remove sections containing debugging information. In some cases [-R] will be useful to remove sections which contain information that is not needed by the binary file.
Consider the source file's object format to be bfdname, rather than attempting to deduce it.See Section "Target Selection", for more information.
Write the output file using the object format bfdname. See Section.Dq Target Selection , for more information.
Use bfdname as the object format for both the input and the output file; i.e., simply transfer data from source to destination with no translation.See Section "Target Selection", for more information.
Useful when transforming a raw binary input file into an object file. In this case the output architecture can be set to bfdarch. This option will be ignored if the input file has a known bfdarch. You can access this binary data inside a program by referencing the special symbols that are created by the conversion process. These symbols are called _binary_ objfile _start, _binary_ objfile _end and _binary_ objfile _size. e.g. you can transform a picture file into an object file and then access it in your code using these symbols.
In an ELF object, mark all symbols that have hidden or internal visibility as local. This option applies on top of symbol-specific localization options such as [-L].
would cause objcopy to weaken all symbols that start with "fo" except for the symbol "foo".
Keep only every byte th byte of the input file (header data is not affected). byte can be in the range from 0 to interleave -1, where interleave is given by the [-i] or [--interleave] option, or the default of 4. This option is useful for creating files to program rom. It is typically used with an srec output target.
Only copy one out of every interleave bytes. Select which byte to copy with the [-b] or [--byte] option. The default is 4. objcopy ignores this option if you do not specify either [-b] or [--byte].
Pad the output file up to the load address address. This is done by increasing the size of the last section. The extra space is filled in with the value specified by [--gap-fill] (default zero).
Set or change both the VMA address and the LMA address of the named section. If = is used, the section address is set to val. Otherwise, val is added to or subtracted from the section address. See the comments under [--change-addresses], above. If section does not exist in the input file, a warning will be issued, unless [--no-change-warnings] is used.
Set or change the LMA address of the named section. The LMA address is the address where the section will be loaded into memory at program load time. Normally this is the same as the VMA address, which is the address of the section at program run time, but on some systems, especially those where a program is held in ROM, the two can be different. If = is used, the section address is set to val. Otherwise, val is added to or subtracted from the section address. See the comments under [--change-addresses], above. If section does not exist in the input file, a warning will be issued, unless [--no-change-warnings] is used.
Set or change the VMA address of the named section. The VMA address is the address where the section will be located once the program has started executing. Normally this is the same as the LMA address, which is the address where the section will be loaded into memory, but on some systems, especially those where a program is held in ROM, the two can be different. If = is used, the section address is set to val. Otherwise, val is added to or subtracted from the section address. See the comments under [--change-addresses], above. If section does not exist in the input file, a warning will be issued, unless [--no-change-warnings] is used.
If [--change-section-address] or [--change-section-lma] or [--change-section-vma] is used, and the named section does not exist, issue a warning. This is the default.
Do not issue a warning if [--change-section-address] or [--adjust-section-lma] or [--adjust-section-vma] is used, even if the named section does not exist.
Set the flags for the named section. The flags argument is a comma separated string of flag names. The recognized names are alloc, contents, load, noload, readonly, code, data, rom, share, and debug. You can set the contents flag for a section which does not have contents, but it is not meaningful to clear the contents flag of a section which does have contents--just remove the section instead. Not all flags are meaningful for all object file formats.
If the first character of a global symbol is a special symbol leading character used by the object file format, remove the character. The most common symbol leading character is underscore. This option will remove a leading underscore from all global symbols. This can be useful if you want to link together objects of different file formats with different conventions for symbol names. This is different from [--change-leading-char] because it always changes the symbol name when appropriate, regardless of the object file format of the output file.
This option is used typically in generating ROM images for problematic target systems. For example, on some target boards, the 32-bit words fetched from 8-bit ROMs are re-assembled in little-endian byte order regardless of the CPU byte order. Depending on the programming model, the endianness of the ROM may need to be modified.
Using --reverse-bytes=2 for the above example, the bytes in the output file would be ordered 21436587.
Using --reverse-bytes=4 for the above example, the bytes in the output file would be ordered 43218765.
By using --reverse-bytes=2 for the above example, followed by --reverse-bytes=4 on the output file, the bytes in the second output file would be ordered 34127856.
Apply [--redefine-sym] to each symbol pair " old new " listed in the file filename. filename is simply a flat file, with one symbol pair per line. Line comments may be introduced by the hash character. This option may be given more than once.
Change all global symbols in the file to be weak. This can be useful when building an object which will be linked against other objects using the [-R] option to the linker. This option is only effective when using an object file format which supports weak symbols.
Apply [--keep-symbol] option to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
Apply [--strip-symbol] option to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
Apply [--strip-unneeded-symbol] option to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
Apply [--keep-global-symbol] option to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
Apply [--localize-symbol] option to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
Apply [--globalize-symbol] option to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
Apply [--weaken-symbol] option to each symbol listed in the file filename. filename is simply a flat file, with one symbol name per line. Line comments may be introduced by the hash character. This option may be given more than once.
If the output architecture has alternate machine codes, use the index th code instead of the default one. This is useful in case a machine is assigned an official code and the tool-chain adopts the new code, but other applications still depend on the original code being used. For ELF based architectures if the index alternative does not exist then the value is treated as an absolute number to be stored in the e_machine field of the ELF header.
When stripping a file, perhaps with [--strip-debug] or [--strip-unneeded], retain any symbols specifying source file names, which would otherwise get stripped.
Strip a file, removing contents of any sections that would not be stripped by [--strip-debug] and leaving the debugging sections intact. In ELF files, this preserves all note sections in the output.
i.e., the file pointed to by the [--add-GNU-debuglink] can be the full executable. It does not have to be a file created by the [--only-keep-debug] switch.
Note - this switch is only intended for use on fully linked files. It does not make sense to use it on object files where the debugging information may be incomplete. Besides the GNU_debuglink feature currently only supports the presence of one filename containing debugging information, not multiple filenames on a one-per-object-file basis.
sets the file's start address to zero.
This option is used to build a .sym file for a VxWorks kernel. It can also be a useful way of reducing the size of a [--just-symbols] linker input file.
Verbose output: list all object files modified. In the case of archives, objcopy -V lists all members of the archive.
objfile ...are the object files to be examined. When you specify archives, objdump shows information on each of the member object files.
The long and short forms of options, shown here as alternatives, are equivalent. At least one option from the list [-a,-d,-D,-e,-f,-g,-G,-h,-H,-p,-r,-R,-s,-S,-t,-T,-V,-x] must be given.
displays summary information from the section headers ( [-h]) of fu.o, which is explicitly identified ( [-m]) as a VAX object file in the format produced by Oasys compilers. You can list the formats available with the [-i] option.See Section "Target Selection", for more information.
Display debugging information. This attempts to parse debugging information stored in the file and print it out using a C like syntax. Only certain types of debugging information have been implemented. Some other types are supported by readelf(-w). See Section.Dq readelf .
Like [-g], but the information is generated in a format compatible with ctags tool.
Like [-d], but disassemble the contents of all sections, not just those expected to contain instructions.
Specify that when displaying interlisted source code/disassembly (assumes [-S]) from a file that has not yet been displayed, extend the context to the start of the file.
File segments may be relocated to nonstandard addresses, for example by using the [-Ttext], [-Tdata], or [-Tbss] options to ld. However, some object file formats, such as a.out, do not store the starting address of the file segments. In those situations, although ld relocates the sections correctly, using objdump -h to list the file section headers cannot show the correct addresses. Instead, it shows the usual addresses, which are implicit for the target.
Display a list showing all architectures and object formats available for specification with [-b] or [-m].
Label the display (using debugging information) with the filename and source line numbers corresponding to the object code or relocs shown. Only useful with [-d], [-D], or [-r].
Specify the architecture to use when disassembling object files. This can be useful when disassembling object files which do not describe architecture information, such as S-records. You can list the available architectures with the [-i] option.
Pass target specific information to the disassembler. Only supported on some targets. If it is necessary to specify more than one disassembler option then multiple [-M] options can be used or can be placed together into a comma separated list.
If the target is an ARM architecture then this switch can be used to select which register name set is used during disassembler. Specifying [-M reg-names-std] (the default) will select the register names as used in ARM's instruction set documentation, but with register 13 called 'sp', register 14 called 'lr' and register 15 called 'pc'. Specifying [-M reg-names-apcs] will select the name set used by the ARM Procedure Call Standard, whilst specifying [-M reg-names-raw] will just use r followed by the register number.
There are also two variants on the APCS register naming scheme enabled by [-M reg-names-atpcs] and [-M reg-names-special-atpcs] which use the ARM/Thumb Procedure Call Standard naming conventions. (Either with the normal register names or the special register names).
This option can also be used for ARM architectures to force the disassembler to interpret all instructions as Thumb instructions by using the switch [--disassembler-options=force-thumb]. This can be useful when attempting to disassemble thumb code produced by other compilers.
For the x86, some of the options duplicate functions of the [-m] switch, but allow finer grained control. Multiple selections from the following may be specified as a comma separated string. [x86-64], [i386] and [i8086] select disassembly for the given architecture. [intel] and [att] select between intel syntax mode and AT&T syntax mode. [addr64], [addr32], [addr16], [data32] and [data16] specify the default address size and operand size. These four options will be overridden if [x86-64], [i386] or [i8086] appear later in the option string. Lastly, [suffix], when in AT&T mode, instructs the disassembler to print a mnemonic suffix even when the suffix could be inferred by the operands.
For PPC, [booke], [booke32] and [booke64] select disassembly of BookE instructions.  and  select PowerPC and PowerPC64 disassembly, respectively. [e300] selects disassembly for the e300 family.  selects disassembly for the PowerPC 440.
Print HWR (hardware register, used by the rdhwr instruction) names as appropriate for the CPU or architecture specified by ARCH. By default, HWR names are selected according to the architecture and CPU of the binary being disassembled.
For any of the options listed above, ABI or ARCH may be specified as numeric to have numbers printed rather than names, for the selected types of registers. You can list the available values of ABI and ARCH using the [--help] option.
For VAX, you can specify function entry addresses with [-M entry:0xf00ba]. You can use this multiple times to properly disassemble VAX binary files that don't contain symbol tables (like ROM dumps). In these cases, the function entry mask would otherwise be decoded as VAX instructions, which would probably lead the rest of the function being wrongly disassembled.
Print the relocation entries of the file. If used with [-d] or [-D], the relocations are printed interspersed with the disassembly.
Print the dynamic relocation entries of the file. This is only meaningful for dynamic objects, such as certain types of shared libraries.
Display source code intermixed with disassembly, if possible. Implies [-d].
When disassembling instructions, print the instruction in hex as well as in symbolic form. This is the default except when [--prefix-addresses] is used.
When disassembling instructions, do not print the instruction bytes. This is the default when [--prefix-addresses] is used.
Display the full contents of any sections requested. Display the contents of the .stab and .stab.index and .stab.excl sections from an ELF file. This is only useful on systems (such as Solaris 2.0) in which .stab debugging symbol-table entries are carried in an ELF section. In most other file formats, debugging symbol-table entries are interleaved with linkage symbols, and are visible in the [--syms] output. For more information on stabs symbols, see Top,Stabs,Stabs Overview,stabs.info, The "stabs" debug format.
Start displaying data at the specified address. This affects the output of the [-d], [-r] and [-s] options.
Stop displaying data at the specified address. This affects the output of the [-d], [-r] and [-s] options.
Print the symbol table entries of the file. This is similar to the information provided by the nm program.
Print the dynamic symbol table entries of the file. This is only meaningful for dynamic objects, such as certain types of shared libraries. This is similar to the information provided by the nm program when given the [-D] ( [--dynamic]) option.
Display all available header information, including the symbol table and relocation entries. Using [-x] is equivalent to specifying all of [-a -f -h -p -r -t].
The GNU ranlib program is another form of GNU ar; running ranlib is completely equivalent to executing ar -s. See Section.Dq ar .
objfile ...are the object files to be examined. If none are specified, the file a.out will be used.
Using one of these options, you can choose whether the output from GNU size resembles output from System V size (using [-A], or [--format=sysv]), or Berkeley size (using [-B], or [--format=berkeley]). The default is the one-line format similar to Berkeley's.
Using one of these options, you can control whether the size of each section is given in decimal ( [-d], or [--radix=10]); octal ( [-o], or [--radix=8]); or hexadecimal ( [-x], or [--radix=16]). In [--radix= number], only the three values (8, 10, 16) are supported. The total size is always given in two radices; decimal and hexadecimal for [-d] or [-x] output, or octal and hexadecimal if you're using [-o].
Specify that the object-code format for objfile is bfdname. This option may not be necessary; size can automatically recognize many formats.See Section "Target Selection", for more information.
For each file given, GNU strings prints the printable character sequences that are at least 4 characters long (or the number given with the options below) and are followed by an unprintable character. By default, it only prints the strings from the initialized and loaded sections of object files; for other types of files, it prints the strings from the whole file.
Do not scan only the initialized and loaded sections of object files; scan the whole files.
-o Like -t o. Some other versions of strings have [-o] act like -t d instead. Since we can not be compatible with both ways, we simply chose one.
Print the offset within the file before each string. The single character argument specifies the radix of the offset--- o for octal, x for hexadecimal, or d for decimal.
Select the character encoding of the strings that are to be found. Possible values for encoding are: s = single-7-bit-byte characters (ASCII, ISO 8859, etc., default), S = single-8-bit-byte characters, b = 16-bit bigendian, l = 16-bit littleendian, B = 32-bit bigendian, L = 32-bit littleendian. Useful for finding wide character strings.
Treat the original objfile as a file with the object code format bfdname, and rewrite it in the same format.See Section "Target Selection", for more information.
Treat the original objfile as a file with the object code format bfdname. See Section.Dq Target Selection , for more information.
Replace objfile with a file in the output format bfdname. See Section.Dq Target Selection , for more information.
Remove symbol symbolname from the source file. This option may be given more than once, and may be combined with strip options other than [-K].
would cause strip to only keep symbols that start with the letters "fo", but to discard the symbol "foo".
ie the file pointed to by the [--add-GNU-debuglink] can be the full executable. It does not have to be a file created by the [--only-keep-debug] switch.
The C++ and Java languages provide function overloading, which means that you can write many functions with the same name, providing that each function takes parameters of different types. In order to be able to distinguish these similarly named functions C++ and Java encode them into a low-level assembler name which uniquely identifies each different version. This process is known as mangling. The c++filt program does the inverse mapping: it decodes ( demangles) low-level names into user-level names so that they can be read.
Attempt to demangle types as well as function names. This is disabled by default since mangled types are normally only used internally in the compiler, and they can be confused with non-mangled names. eg a function called "a" treated as a mangled type name would be demangled to "signed char".
Do not include implementation details (if any) in the demangled output.
gnat the one used by the GNU Ada compiler (GNAT).
The executable or relocatable object to use is specified with the [-e] option. The default is the file a.out. The section in the relocatable object to use is specified with the [-j] option.
nlmconv converts a relocatable object file into a NetWare Loadable Module.
" Warning: nlmconv is not always built as part of the binary utilities, since it is only useful for NLM targets. "
nlmconv converts the relocatable i386 object file infile into the NetWare Loadable Module outfile, optionally reading headerfile for NLM header information. For instructions on writing the NLM command file language used in header files, see the linkers section, NLMLINK in particular, of the NLM Development and Tools Overview, which is part of the NLM Software Developer's Kit ("NLM SDK"), available from Novell, Inc. nlmconv uses the GNU Binary File Descriptor library to read infile; see BFD,,BFD,ld.info,Using LD, for more information.
Object format of the input file. nlmconv can usually determine the format of a given file (so no default is necessary).See Section "Target Selection", for more information.
Object format of the output file. nlmconv infers the output format based on the input format, e.g. for a i386 input file the output format is nlm32-i386. See Section.Dq Target Selection , for more information.
windmc may be used to generator Windows message resources.
" Warning: windmc is not always built as part of the binary utilities, since it is only useful for Windows targets. "
h A C header file containing the message definitions.
rc A resource file compilable by the windres tool.
bin One or more binary files containing the resource data for a specific message language.
dbg A C include file that maps message id's to their symbolic name.
When windmc converts from the mc format to the bin format, rc, h, and optional dbg it is acting like the Windows Message Compiler.
Specifies that messages in the output bin files should be in ANSI format.
Specifies that bin filenames should have to be prefixed by the basename of the source file.
Specify the BFD format to use for a bin file as output. This is a BFD target name; you can use the [--help] option to see a list of supported targets. Normally windmc will use the default format, which is the first one listed by the [--help] option. Target Selection.
Terminate message text in bin files by zero. By default they are terminated by CR/LF.
Not yet implemented. Instructs windmc to generate an OLE2 header file, using HRESULT definitions. Status codes are used if the flag is not specified.
The target directory for the generated rc script and the generated bin files that the resource compiler script includes. The default is the current directory.
Specifies that messages in the output bin file should be in UTF16 format. This is the default behaviour.
Enable verbose mode. This tells you what the preprocessor is if you didn't specify one.
The path of the dbg C include file that maps message id's to the symbolic name. No such file is generated without specifying the switch.
windres may be used to manipulate Windows resources.
" Warning: windres is not always built as part of the binary utilities, since it is only useful for Windows targets. "
rc A text format read by the Resource Compiler.
res A binary format generated by the Resource Compiler.
coff A COFF object or executable.
When windres converts from the rc format to the res format, it is acting like the Windows Resource Compiler. When windres converts from the res format to the coff format, it is acting like the Windows CVTRES program.
When windres generates an rc file, the output is similar but not identical to the format expected for the input. When an input rc file refers to an external filename, an output rc file will instead include the file contents.
If the input or output format is not specified, windres will guess based on the file name, or, for the input file, the file contents. A file with an extension of .rc will be treated as an rc file, a file with an extension of .res will be treated as a res file, and a file with an extension of .o or .exe will be treated as a coff file.
If no output file is specified, windres will print the resources in rc format to standard output.
The normal use is for you to write an rc file, use windres to convert it to a COFF object file, and then link the COFF file into your application. This will make the resources described in the rc file available to Windows.
The name of the output file. If this option is not used, then windres will use the first non-option argument, after any used for the input file name, as the output file name. If there is no non-option argument, then windres will write to standard output. windres can not write a COFF file to standard output. Note, for compatibility with rc the option [-fo] is also accepted, but its use is not recommended.
Specify the BFD format to use for a COFF file as input or output. This is a BFD target name; you can use the [--help] option to see a list of supported targets. Normally windres will use the default format, which is the first one listed by the [--help] option. Target Selection.
When windres reads an rc file, it runs it through the C preprocessor first. This option may be used to specify the preprocessor to use, including any leading arguments. The default preprocessor argument is gcc -E -xc-header -DRC_INVOKED.
Specify an include directory to use when reading an rc file. windres will pass this to the preprocessor as an [-I] option. windres will also search this directory when looking for files named in the rc file. If the argument passed to this command matches any of the supported formats (as described in the [-J] option), it will issue a deprecation warning, and behave just like the [-J] option. New programs should not use this behaviour. If a directory happens to match a format, simple prefix it with ./ to disable the backward compatibility.
Specify a [-D] option to pass to the preprocessor when reading an rc file.
Specify a [-U] option to pass to the preprocessor when reading an rc file.
-r Ignored for compatibility with rc.
-v Enable verbose mode. This tells you what the preprocessor is if you didn't specify one.
Specify the default codepage to use when reading an rc file. val should be a hexadecimal prefixed by 0x or decimal codepage code. The valid range is from zero up to 0xffff, but the validity of the codepage is host and configuration dependent.
Specify the default language to use when reading an rc file. val should be a hexadecimal language code. The low eight bits are the language, and the high eight bits are the sublanguage.
If windres is compiled with YYDEBUG defined as 1, this will turn on parser debugging.
dlltool is used to create the files needed to create dynamic link libraries (DLLs) on systems which understand PE format image files such as Windows. A DLL contains an export table which contains information that the runtime loader needs to resolve references from a referencing program.
The export table is generated by this program by reading in a .def file or scanning the .a and .o files which will be in the DLL. A .o file can contain information in special .drectve sections with export information.
" Note: dlltool is not always built as part of the binary utilities, since it is only useful for those targets which support DLLs. "
dlltool reads its inputs, which can come from the [-d] and [-b] options as well as object files specified on the command line. It then processes these inputs and if the [-e] option has been specified it creates a exports file. If the [-l] option has been specified it creates a library file and if the [-z] option has been specified it creates a def file. Any or all of the [-e], [-l] and [-z] options can be present in one invocation of dlltool.
The first file is a .def file which specifies which functions are exported from the DLL, which functions the DLL imports, and so on. This is a text file and can be created by hand, or dlltool can be used to create it using the [-z] option. In this case dlltool will scan the object files specified on its command line looking for those functions which have been specially marked as being exported and put entries for them in the .def file it creates.
The second file needed for DLL creation is an exports file. This file is linked with the object files that make up the body of the DLL and it handles the interface between the DLL and the outside world. This is a binary file and it can be created by giving the [-e] option to dlltool when it is creating or reading in a .def file.
The third file needed for DLL creation is the library file that programs will link with in order to access the functions in the DLL. This file can be created by giving the [-l] option to dlltool when it is creating or reading in a .def file.
dlltool builds the library file by hand, but it builds the exports file by creating temporary files containing assembler statements and then assembling these. The [-S] command line option can be used to specify the path to the assembler that dlltool will use, and the [-f] option can be used to pass specific flags to that assembler. The [-n] can be used to prevent dlltool from deleting these temporary assembler files when it is done, and if [-n] is specified twice then this will prevent dlltool from deleting the temporary object files it used to build the library.
Treat all global and weak defined symbols found in the input object files as symbols to be exported. There is a small list of symbols which are not exported by default; see the [--no-default-excludes] option. You may add to the list of symbols to not export by using the [--exclude-symbols] option.
Do not export the symbols in list. This is a list of symbol names separated by comma or colon characters. The symbol names should not contain a leading underscore. This is only meaningful when [--export-all-symbols] is used.
When [--export-all-symbols] is used, it will by default avoid exporting certain special symbols. The current list of symbols to avoid exporting is DllMain@12, DllEntryPoint@0, impure_ptr. You may use the [--no-default-excludes] option to go ahead and export these special symbols. This is only meaningful when [--export-all-symbols] is used.
Specifies any specific command line options to be passed to the assembler when building the exports file. This option will work even if the [-S] option is not used. This option only takes one argument, and if it occurs more than once on the command line, then later occurrences will override earlier occurrences. So if it is necessary to pass multiple options to the assembler they should be enclosed in double quotes.
Specifies the name to be stored in the .def file as the name of the DLL when the [-e] option is used. If this option is not present, then the filename given to the [-e] option will be used as the name of the DLL.
Specifies that when dlltool is creating the exports file it should not append the string @ <number>. These numbers are called ordinal numbers and they represent another way of accessing the function in a DLL, other than by name.
Specifies that when dlltool is creating the exports and library files it should omit the .idata4 section. This is for compatibility with certain operating systems.
Specifies that when dlltool is creating the exports and library files it should omit the .idata5 section. This is for compatibility with certain operating systems.
The result is going to be named name .exe.
The result is going to be named name .dll.
Declares name1 as an exported symbol from the DLL, with optional ordinal number integer, or declares name1 as an alias (forward) of the function external-name in the DLL module-name.
Declares that external-name or the exported function whose ordinal number is integer is to be imported from the file module-name. If internal-name is specified then this is the name that the imported function will be referred to in the body of the DLL.
Puts string into the output .exp file in the .rdata section.
Generates --stack or --heap number-reserve , number-commit in the output .drectve section. The linker will see this and act upon it.
Generates --attr section-name attr in the output .drectve section, where attr is one of READ, WRITE, EXECUTE or SHARED. The linker will see this and act upon it.
elffile ...are the object files to be examined. 32-bit and 64-bit ELF files are supported, as are archives containing ELF files.
Equivalent to specifying [--file-header], [--program-headers], [--sections], [--symbols], [--relocs], [--dynamic], [--notes] and [--version-info].
Displays the detailed section information. Implies [-S].
Display all the headers in the file. Equivalent to [-h -l -S].
Displays the contents of the file's unwind section, if it has one. Only the unwind sections for IA64 ELF files are currently supported.
When displaying symbols, this option makes readelf use the symbol table in the file's dynamic section, rather than the one in the symbols section.
Displays the contents of the indicated section as a hexadecimal dump. A number identifies a particular section by index in the section table; any other string identifies all sections with that name in the object file.
The following command-line options are supported by all of the programs described in this manual.
Read command-line options from file. The options read are inserted in place of the original @ file option. If file does not exist, or cannot be read, then the option will be treated literally, and not removed.
Options in file are separated by whitespace. A whitespace character may be included in an option by surrounding the entire option in either single or double quotes. Any character (including a backslash) may be included by prefixing the character to be included with a backslash. The file may itself contain additional @ file options; any such options will be processed recursively.
Display the command-line options supported by the program.
Display the version number of the program.
In the following summaries, the lists of ways to specify values are in order of decreasing precedence. The ways listed first override those listed later.
The commands to list valid values only list the values for which the programs you are running were configured. If they were configured with [--enable-targets=all], the commands list most of the available values, but a few are left out; not all targets can be configured in at once because some of them can only be configured native (on hosts with the same type as the target system).
A target is an object file format. A given target may be supported for multiple architectures (see Section "Architecture Selection"). A target selection may also have variations for different operating systems or architectures.
The command to list valid target values is objdump -i (the first column of output contains the relevant information).
Some sample values are: a.out-hp300bsd, ecoff-littlemips, a.out-sunos-big.
You can also specify a target using a configuration triplet. This is the same sort of name that is passed to configure to specify a target. When you use a configuration triplet as an argument, it must be fully canonicalized. You can see the canonical version of a triplet by running the shell script config.sub which is included with the sources.
Some sample configuration triplets are: m68k-hp-bsd, mips-dec-ultrix, sparc-sun-sunos.
An architecture is a type of cpu on which an object file is to run. Its name may contain a colon, separating the name of the processor family from the name of the particular cpu.
The command to list valid architecture values is objdump -i (the second column contains the relevant information).
Sample values: m68k:68020, mips:3000, sparc.
Your bug reports play an essential role in making the binary utilities reliable.
Reporting a bug may help you by bringing a solution to your problem, or it may not. But in any case the principal function of a bug report is to help the entire community by making the next version of the binary utilities work better. Bug reports are your contribution to their maintenance.
If a binary utility gets a fatal signal, for any input whatever, that is a bug. Reliable utilities never crash.
If a binary utility produces an error message for valid input, that is a bug.
If you are an experienced user of binary utilities, your suggestions for improvement are welcome in any case.
A number of companies and individuals offer support for GNU products. If you obtained the binary utilities from a support organization, we recommend you contact that organization first.
You can find contact information for many support companies and individuals in the file etc/SERVICE in the GNU Emacs distribution.
Often people omit facts because they think they know what causes the problem and assume that some details do not matter. Thus, you might assume that the name of a file you use in an example does not matter. Well, probably it does not, but one cannot be sure. Perhaps the bug is a stray memory reference which happens to fetch from the location where that pathname is stored in memory; perhaps, if the pathname were different, the contents of that location would fool the utility into doing the right thing despite the bug. Play it safe and give a specific, complete example. That is the easiest thing for you to do, and the most helpful.
Keep in mind that the purpose of a bug report is to enable us to fix the bug if it is new to us. Therefore, always write your bug reports on the assumption that the bug has not been reported previously.
Sometimes people give a few sketchy facts and ask, "Does this ring a bell?" This cannot help us fix a bug, so it is basically useless. We respond by asking for enough details to enable us to investigate. You might as well expedite matters by sending them to begin with.
The version of the utility. Each utility announces it if you start it with the [--version] argument.
Without this, we will not know whether there is any point in looking for the bug in the current version of the binary utilities.
Any patches you may have applied to the source, including any patches made to the BFD library.
What compiler (and its version) was used to compile the utilities---e.g. " gcc-2.7 ".
The command arguments you gave the utility to observe the bug. To guarantee you will not omit something important, list them all. A copy of the Makefile (or the output from make) is sufficient.
If we were to try to guess the arguments, we would probably guess wrong and then we might not encounter the bug.
A complete input file, or set of input files, that will reproduce the bug. If the utility is reading an object file or files, then it is generally most helpful to send the actual object files.
If the source files were produced exclusively using GNU programs (e.g., gcc, gas, and/or the GNU ld), then it may be OK to send the source files rather than the object files. In this case, be sure to say exactly what version of gcc, or whatever, was used to produce the object files. Also say how gcc, or whatever, was configured.
Of course, if the bug is that the utility gets a fatal signal, then we will certainly notice it. But if the bug is incorrect output, we might not notice unless it is glaringly wrong. You might as well not give us a chance to make a mistake.
Even if the problem you experience is a fatal signal, you should still say so explicitly. Suppose something strange is going on, such as your copy of the utility is out of sync, or you have encountered a bug in the C library on your system. (This has happened!) Your copy might crash and ours would not. If you told us to expect a crash, then when ours fails to crash, we would know that the bug was not happening for us. If you had not told us to expect a crash, then we would not be able to draw any conclusion from our observations.
If you wish to suggest changes to the source, send us context diffs, as generated by diff with the [-u], [-c], or [-p] option. Always send diffs from the old file to the new file. If you wish to discuss something in the ld source, refer to it by context, not by line number.
The line numbers in our development sources will not match those in your sources. Your line numbers would convey no useful information to us.
This is often time consuming and not very useful, because the way we will find the bug is by running a single example under the debugger with breakpoints, not by pure deduction from a series of examples. We recommend that you save your time for something else.
Of course, if you can find a simpler example to report instead of the original one, that is a convenience for us. Errors in the output will be easier to spot, running under the debugger will take less time, and so on.
However, simplification is not vital; if you do not want to do this, report the bug anyway and send us the entire test case you used.
A patch for the bug does help us if it is a good one. But do not omit the necessary information, such as the test case, on the assumption that a patch is all we need. We might see problems with your patch and decide to fix the problem another way, or we might not understand it at all.
Sometimes with programs as complicated as the binary utilities it is very hard to construct an example that will make the program follow a certain path through the code. If you do not send us the example, we will not be able to construct one, so we will not be able to verify that the bug is fixed.
And if we cannot understand what bug you are trying to fix, or why your patch should be an improvement, we will not install it. A test case will help us to understand.
Such guesses are usually wrong. Even we cannot guess right about such things without first using the debugger to find the facts.
The purpose of this License is to make a manual, textbook, or other written document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others.
This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software.
A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language.
A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them.
The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License.
The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License.
The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text.
A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has less than five). C. State on the Title page the name of the publisher of the Modified Version, as the publisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. H. Include an unaltered copy of this License. I. Preserve the section entitled "History", and its title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. In any section entitled "Acknowledgements" or "Dedications", preserve the section's title, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section entitled "Endorsements." Such a section may not be included in the Modified Version. N. Do not retitle any existing section as "Endorsements" or to conflict in title with any Invariant Section.
You may add a section entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard.
A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, does not as a whole count as a Modified Version of the Document, provided no compilation copyright is claimed for the compilation. Such a compilation is called an "aggregate", and this License does not apply to the other self-contained works thus compiled with the Document, on account of their being thus compiled, if they are not themselves derivative works of the Document.
Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.
If you have no Invariant Sections, write "with no Invariant Sections" instead of saying which ones are invariant. If you have no Front-Cover Texts, write "no Front-Cover Texts" instead of "Front-Cover Texts being list "; likewise for Back-Cover Texts.


text:
There is a lot of excitement about nanotechnology. "Nano" has become a familiar term in the world today but there is often little understanding of what it is. For example, a poll of 1,001 adults in 2009 found 90 percent of Americans think that the public should be better informed about the development of cutting-edge technologies like nanotechnology (Project on Emerging Nanotechnologies). We will provide some basics that can help you understand more about nanotechnology and especially about how the safety of products made with nanotechnology is established.
Nanotechnology is the phenomenon and manipulation of materials at atomic, molecular and macromolecular scales. Within this definition are the particles and other forms of materials that are created or manipulated at the nanoscale. Most attempts to describe and categorize nanomaterials have used size to define nanomaterials. The most commonly used size range is 1-100 nanometers (nm) although some definitions include sizes up to 1,000 nm. For perspective, a nanometer is one billionth of a meter. A single grain of salt is about 300,000 nm in diameter. A human hair is about 100,000 nm in diameter. For a fascinating perspective of this scale, click here.
The picture above accompanying this topic shows stylized images of nanoscale forms of carbon called fullerenes. The fullerene forms of carbon can take on various shapes including spheres (buckministerfullerenes), tubes (carbon nanotubes) and sheets (fullerene). At the nanoscale, materials begin to display properties not observed at the larger scale. They reflect light differently. In addition, some other fundamental properties like melting point, electrical conductivity, magnetic properties, fluorescence, and chemical reactivity can change as a function of the size of the material.
Gold is a good example of a material which displays different properties at the nanoscale. We are all familiar with gold as a precious metal. Its yellow color and resistance to tarnishing makes it an attractive choice for jewelry or as a corrosion-resistant material for high-end electrical connectors. However, take some gold particles and pound them down to a thin film of just a few nanometers in thickness as goldsmiths in the middle ages did and the color shifts from yellow to red and purple. In addition, at this scale, rather than being an inert metal, gold becomes capable of catalyzing chemical reactions. This makes nanoscale gold a very different material from its larger form. Click here to learn more about how, even further back in history, the ancients took advantage of the properties of nanotechnology. One example is the Lycurgus cup pictured here.
What else makes nanoscale materials useful?
In nature, nanoscale properties are responsible for the self-cleaning properties of the lotus leaf (https://www.youtube.com/watch?v=VHcd_4ftsNY) or the intense and iridescent colors of the monarch butterfly or the shimmering opalescence of pearls. By studying these types of effects in nature, man has been able to reapply some of these properties to bring new functions and capabilities that can be useful for a wide variety of applications from environmental clean-up, energy production, electronics, medicine, cleaning products, cosmetics, and food production.
Some specific examples of how nanotechnology has been applied include:
• Ground water clean-up – Nanoscale materials such as iron have been used to successfully clean up groundwater contaminated with chlorinated solvents such as trichloroethylene. Nanotechnology has also been applied to groundwater remediation of many other types of contaminants as well. Click here for a link to a review of the use of nanotechnology in the remediation of several examples of contaminants.
• Flat panel displays – Modern flat panel displays, such as on your TV or computer display, are brighter and can produce more realistic colors thanks to the tunable light-emitting properties of the materials used to generate the images.
• Sunscreen – Many sunscreens contain nanoparticles of zinc oxide or titanium oxide. Sunscreen formulas using nanoscale forms of these materials are almost invisible on the skin compared to the older formulations using the larger size particles. The small size also improves the uniformity of coverage on the skin and improves the overall effectiveness the sunscreen at protecting from UV radiation.
• Self-cleaning glass – Some materials such as silicon dioxide (ordinary sand) can have photocatalytic effects at the nanoscale. When UV radiation from light hits the glass, the nanoparticles become energized and begin to break down and loosen organic molecules ("dirt") on the glass.
• Clothing – Nanotechnology is being used to enhance your clothing. By coating fabrics with a thin layer of zinc oxide nanoparticles, manufacturers can create clothes that give better protection from UV radiation. Some clothes have nanoparticles in the form of little hairs or whiskers that help repel water and other materials, making the clothing stain-resistant.
• Scratch-resistant coatings – Engineers discovered that adding aluminum silicate nanoparticles to scratch-resistant polymer coatings made the coatings more effective, increasing resistance to chipping and scratching. Scratch-resistant coatings are common on everything from cars to eyeglass lenses.
• Nano-enabled packaging – Common packaging films such as polyethylene are being improved by including nanoscale materials such as clays in the film to further reduce permeability to gases and moisture. The result is a packaging film that is more effective at protecting freshness.
There are many other examples how nanotechnology is being used. Since 2007 the Woodrow Wilson Center project on Emerging Nanotechnologies has been compiling a list of consumer projects on the market that utilize, or claim to use, some aspect of nanotechnology to improve performance over conventional products. Click here to see this list, which, while not necessarily comprehensive, illustrates how broadly nanotechnology can be applied.
How do we know if products made with nanotechnology are safe?
Now that we know what it is and how it can be used, we come to the next question of how the safety of nanotechnology is determined. As with any material, the risks associated with using nanoscale materials depends on understanding both hazards and exposure. Recall that hazard is the inherent ability of something to cause harm while exposure is the level that is predicted to cause the harm. Together these two elements form the basis for assessing the risk posed by a chemical. See our post on Hazard vs Risk for a more complete description.
The primary uncertainty in understanding for potential hazards associated with nanotechnology whether there are unique biological effects caused by novel surface chemistry found only at the nanoscale. This has been an area of intense study and a pattern is emerging that suggests these effects may be predicted with tools provided by quantum theory. In the meantime, the biological effects caused by surface chemistry are currently evaluated by toxicologists on a case-by-case basis for each nanomaterial through by testing each of the variants of a nanoscale material.
There are also other questions related to exposure. Because of their small size, do nanoparticles reach parts of the body that larger size particles cannot? It appears that nanoparticles applied to the skin tend to stay on the surface of the skin and are not likely to reach other parts of the body. However, we also know that some inhaled nanomaterials can move to parts of the body that their larger scale cousins cannot reach. Do they cause harm in this case?
Fortunately it appears that most methods available for answering these questions for traditional materials can be used to answer questions about nanomaterials. In a massive multi-national effort sponsored by the Organization for Economic Cooperation and Development (OECD) that spanned more than seven years, the methods used to evaluate the toxicity of more traditional chemicals were found to be appropriate for the evaluation of nanomaterials (http://www.oecd.org/chemicalsafety/nanosafety/testing-programme-manufactured-nanomaterials.htm).
In 2007 a framework for evaluating nanomaterial was developed in a joint effort between DuPont and Environmental Defense that has served to guide the development and sustainable application of nanotechnology across numerous industries. Government agencies around the world have also been developing regulatory strategies to ensure that nanomaterials in commerce and products using nanotechnology are safe. For instance, in the United States, both the Food and Drug Administration (FDA) and the Environmental Protection Agency (EPA) have issued guidelines for the responsible development of nanomaterials and expectations for assessing safety.
Work continues to improve techniques and approaches for evaluating nanoscale materials but the fundamental tools are in place to evaluate potential health or environmental effects from nanoscale materials.
Nanotechnology holds great promise for improving lives and protecting the environment. However, there is a continuous need to evaluate whether there are risks associated with specific nanomaterials and determine whether a particular application is safe. Fortunately this is well recognized across the scientific and regulatory community and efforts are ongoing to ensure that the best tools are developed and applied appropriately to evaluate these materials.
Resources for further information:
EPA on nanomaterials—http://www2.epa.gov/chemical-research/research-evaluating-nanomaterials-chemical-safety
FDA on nanotechnology— http://www.fda.gov/scienceresearch/specialtopics/nanotechnology/default.htm
National Institutes of Health/National Institute of Environmental Health Science on nanomaterials – http://www.niehs.nih.gov/health/topics/agents/sya-nano/
National Nanotechnology Initiative (NNI)—http://www.nano.gov/about-nni
Risk Bytes (University of Michigan Center for Risk Analysis)
Nanoparticles and Sun Screens: https://www.youtube.com/watch?v=VV0cCg4clMw
What you should know about silver nanoparticles: https://www.youtube.com/watch?v=Yz6LuH-11II
Society of Toxicology on nanotechnology–https://www.toxicology.org/script/admin/toxtopics/114719_AM_TT4_NanotechnologySOT.pdf
Woodrow Wilson Center – Project on Emerging Nanotechnologies—http://www.nanotechproject.org/
Source of image showing nanoscale forms of carbon: Wikimedia Commons
Related topic: Hazard vs risk
Travel Awards March 2, 2022
Perchlorate in Drinking Water November 23, 2020
Pain Relievers and Pregnancy- Q&A October 27, 2020
Threshold of Toxicological Concern September 9, 2020
Methanol Toxicity July 29, 2020
Topic Cateogries
Activity (4)
Dose-Response (1)
Environmental toxicology (3)
Green Chemistry (1)
In the Classroom (16)
Occupational Toxicology (3)
Product Safety (6)
Tox Topic (33)
Toxicity testing (3)
Travel Awards (1)
Recent Tox News
Past Awards $15,000 IUTOX Risk Assessment Summer School $10,000 Travel …
Perchlorate is an inorganic ion containing one chlorine atom bound …
FDA Labeling Announcement for NSAIDS – What does this mean …
Estimating Potential for Harm: The Threshold of Toxicological Concern …
Methanol, sometimes called wood alcohol, is the simplest of the …

redpajama_set_name: RedPajamaCommonCrawl


text:
namespace v8 {
namespace internal {

const Register CallInterfaceDescriptor::ContextRegister() { return cp; }

const Register LoadDescriptor::ReceiverRegister() { return r1; }
const Register LoadDescriptor::NameRegister() { return r2; }
const Register LoadDescriptor::SlotRegister() { return r0; }

const Register LoadWithVectorDescriptor::VectorRegister() { return r3; }

const Register StoreDescriptor::ReceiverRegister() { return r1; }
const Register StoreDescriptor::NameRegister() { return r2; }
const Register StoreDescriptor::ValueRegister() { return r0; }

const Register VectorStoreICTrampolineDescriptor::SlotRegister() { return r4; }

const Register VectorStoreICDescriptor::VectorRegister() { return r3; }

const Register StoreTransitionDescriptor::MapRegister() { return r3; }

const Register ElementTransitionAndStoreDescriptor::MapRegister() { return r3; }

const Register InstanceofDescriptor::left() { return r0; }
const Register InstanceofDescriptor::right() { return r1; }

const Register ArgumentsAccessReadDescriptor::index() { return r1; }
const Register ArgumentsAccessReadDescriptor::parameter_count() { return r0; }

const Register ApiGetterDescriptor::function_address() { return r2; }

const Register MathPowTaggedDescriptor::exponent() { return r2; }

const Register MathPowIntegerDescriptor::exponent() {
  return MathPowTaggedDescriptor::exponent();
}

const Register GrowArrayElementsDescriptor::ObjectRegister() { return r0; }
const Register GrowArrayElementsDescriptor::KeyRegister() { return r3; }

void FastNewClosureDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r2};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void FastNewContextDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r1};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void ToNumberDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r0};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void NumberToStringDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r0};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void TypeofDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r3};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void FastCloneShallowArrayDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r3, r2, r1};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void FastCloneShallowObjectDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r3, r2, r1, r0};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void CreateAllocationSiteDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r2, r3};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void CreateWeakCellDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r2, r3, r1};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void StoreArrayLiteralElementDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r3, r0};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void CallFunctionDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r1};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void CallFunctionWithFeedbackDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r1, r3};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void CallFunctionWithFeedbackAndVectorDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r1, r3, r2};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void CallConstructDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  // r0 : number of arguments
  // r1 : the function to call
  // r2 : feedback vector
  // r3 : (only if r2 is not the megamorphic symbol) slot in feedback
  //      vector (Smi)
  // TODO(turbofan): So far we don't gather type feedback and hence skip the
  // slot parameter, but ArrayConstructStub needs the vector to be undefined.
  Register registers[] = {r0, r1, r2};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void RegExpConstructResultDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r2, r1, r0};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void TransitionElementsKindDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r0, r1};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void AllocateHeapNumberDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  data->InitializePlatformSpecific(0, nullptr, nullptr);
}

void ArrayConstructorConstantArgCountDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  // register state
  // r0 -- number of arguments
  // r1 -- function
  // r2 -- allocation site with elements kind
  Register registers[] = {r1, r2};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void ArrayConstructorDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  // stack param count needs (constructor pointer, and single argument)
  Register registers[] = {r1, r2, r0};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void InternalArrayConstructorConstantArgCountDescriptor::
    InitializePlatformSpecific(CallInterfaceDescriptorData* data) {
  // register state
  // r0 -- number of arguments
  // r1 -- constructor function
  Register registers[] = {r1};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void InternalArrayConstructorDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  // stack param count needs (constructor pointer, and single argument)
  Register registers[] = {r1, r0};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void CompareDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r1, r0};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void CompareNilDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r0};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void ToBooleanDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r0};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void BinaryOpDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r1, r0};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void BinaryOpWithAllocationSiteDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r2, r1, r0};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void StringAddDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  Register registers[] = {r1, r0};
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void KeyedDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  static PlatformInterfaceDescriptor noInlineDescriptor =
      PlatformInterfaceDescriptor(NEVER_INLINE_TARGET_ADDRESS);

  Register registers[] = {
      r2,  // key
  };
  data->InitializePlatformSpecific(arraysize(registers), registers,
                                   &noInlineDescriptor);
}

void NamedDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  static PlatformInterfaceDescriptor noInlineDescriptor =
      PlatformInterfaceDescriptor(NEVER_INLINE_TARGET_ADDRESS);

  Register registers[] = {
      r2,  // name
  };
  data->InitializePlatformSpecific(arraysize(registers), registers,
                                   &noInlineDescriptor);
}

void CallHandlerDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  static PlatformInterfaceDescriptor default_descriptor =
      PlatformInterfaceDescriptor(CAN_INLINE_TARGET_ADDRESS);

  Register registers[] = {
      r0,  // receiver
  };
  data->InitializePlatformSpecific(arraysize(registers), registers,
                                   &default_descriptor);
}

void ArgumentAdaptorDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  static PlatformInterfaceDescriptor default_descriptor =
      PlatformInterfaceDescriptor(CAN_INLINE_TARGET_ADDRESS);

  Register registers[] = {
      r1,  // JSFunction
      r0,  // actual number of arguments
      r2,  // expected number of arguments
  };
  data->InitializePlatformSpecific(arraysize(registers), registers,
                                   &default_descriptor);
}

void ApiFunctionDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  static PlatformInterfaceDescriptor default_descriptor =
      PlatformInterfaceDescriptor(CAN_INLINE_TARGET_ADDRESS);

  Register registers[] = {
      r0,  // callee
      r4,  // call_data
      r2,  // holder
      r1,  // api_function_address
      r3,  // actual number of arguments
  };
  data->InitializePlatformSpecific(arraysize(registers), registers,
                                   &default_descriptor);
}

void ApiAccessorDescriptor::InitializePlatformSpecific(
    CallInterfaceDescriptorData* data) {
  static PlatformInterfaceDescriptor default_descriptor =
      PlatformInterfaceDescriptor(CAN_INLINE_TARGET_ADDRESS);

  Register registers[] = {
      r0,  // callee
      r4,  // call_data
      r2,  // holder
      r1,  // api_function_address
  };
  data->InitializePlatformSpecific(arraysize(registers), registers,
                                   &default_descriptor);
}

void MathRoundVariantCallFromUnoptimizedCodeDescriptor::
    InitializePlatformSpecific(CallInterfaceDescriptorData* data) {
  Register registers[] = {
      r1,  // math rounding function
      r3,  // vector slot id
  };
  data->InitializePlatformSpecific(arraysize(registers), registers);
}

void MathRoundVariantCallFromOptimizedCodeDescriptor::
    InitializePlatformSpecific(CallInterfaceDescriptorData* data) {
  Register registers[] = {
      r1,  // math rounding function
      r3,  // vector slot id
      r4,  // type vector
  };
  data->InitializePlatformSpecific(arraysize(registers), registers);
}
}  // namespace internal
}  // namespace v8

#endif  // V8_TARGET_ARCH_ARM

redpajama_set_name: RedPajamaGithub


It only comes around once a year, but when it does, boy do we know about it. One of the biggest and most colourful events in London, Notting Hill Carnival is a level of culture, colour and cool that's strictly off the charts. From a parade and stunning outfits, to DJs, dancing and Carnival after-parties, there's no stopping this stunning showcase. Check out our recommendations for all things Notting Hill Carnival 2019.
The culture and colour doesn't stop in Notting Hill. Check out our Notting Hill Carnival after party list for the best late night events, post-parade.
Awash with feathers, features, costumes and local creativity, there's nothing quite like Notting Hill Carnival, anywhere else in the world.
Don't let navigating the festival streets tie you down, our ultimate sound stages at Notting Hill guide will keep you on top of those slick beats.


Information on vanishing twins, events, scholarships and twins in school.
A non-profit, family-oriented organization to promote the spiritual, intellectual, and social welfare of twins and multiples throughout the world.
Mirror twins from Australia share photos, twin stories, links and information on twin festivals and celebrations.
Bulletin boards, twin games, photo gallery, information for parents, TV and movie twins, twin events, and information.
Offerings include a twin casting agency, twin events, reunion of twins placed for adoption or separated at birth, message boards, links, photos, contests, and research.


Tesco has sent total reward statements to staff who have been with the retailer for less than a year for the first time. The move is a bid by the supermarket giant to cut employee turnover by promoting future entitlement to benefits.
Tesco is also using its total reward statements to flag up to all its staff what they could receive on retirement if they joined the company defined benefit (DB) pension scheme.
Until now, employees who are not members only received direct marketing about the DB scheme with their statements. The pension plan is open to all staff, irrespective of when they join, and requires members to contribute 4.75%, while Tesco pays about double that in contributions.
Previously, Tesco only sent total reward statements to staff with more then one year's service. But last month, it produced an extra 40,000 statements for staff with less than a year's service, making a total of 220,000 statements. Also, this year, the statements are printed on environmentally-friendly FSC paper.
Michael Poulton, benefits manager at Tesco, said: "In any retail business, there will be a proportion of staff who won't stay for 12 months – that's a pattern across retail. We want to send the message out to those staff that if they realise what benefits they will get from 12 months onwards, it might incentivise them to stay on further."
The statements sent to staff who have yet to clock up one year's service make it clear that they will be entitled to a 'Privilege' discount card and free shares through the retailer's Shares in success scheme, as well as the chance to participate in its Save as you earn share scheme if they stay on longer than a year.
They also point out that employees who have worked for more than three months are eligible to take part in the Buy as you earn share scheme.


Mark Pike's Port Talbot Town undefeated streak came to an end this past Saturday at Welsh League Divsion 1 new boys Llantwit Major as they were defeated by the narrowest of margins writes Port Talbot Town's Craig Mapstone.
It was the 'Major' that started stronger out of the blocks. Recent signing Luke Cox got the first effort in on goal. He beat his man with a smart move going forward in to the box but his effort was easily saved by the Port Talbot Town keeper.
Darren Robinson followed up with a shot minutes later from distance that was wide of the mark before PTT started to settle in to the game with 15 minutes gone. Jordan Pike's corner knocked towards the near post was cleared comfortably with the away side starting to look the better side.
Keane Watts started to make his presence felt. When Glyn Davies wasn't able to clear a ball knocked over the top Watts' made great use of his pace to latch on to the ball. He managed to get one on one with Jack Lansdown but the home keeper did well to block the effort in at goal.
Port Talbot continued to pile on the pressure with Owain Davies heading towards the near corner of the goal before another corner kick was gained. PTT finally made this count. Pike's delivery wasn't dealt with well by Llantwit Major in the six-yard area as the ball fell towards Blake Morgan who found himself in acres of space. Morgan made no mistake here and smashed the ball in to the bottom corner to put the visitors 1-0 in front.
The most spectacular effort of the game came 10 minutes later with a nice Port Talbot move. Ryan Morgan's throw in to the box was flicked on by Blake which presented Owain Davies with an acrobatic opportunity. His over head kick going just wide of the mark.
Llantwit Major had the better of the chances as the first half drew to it's conclusion. Some nice play on the wing resulted in a low cross driven across the box. Any touch on the end of this would have certainly seen the Major equalising but nobody was able to get on the end of it.
Luke Cox tested again with his headed effort going wide and a fine move going forward for the home side had Anthony Rawlings through on goal. James Harris done well to make himself big and prevent the former Port Talbot Town man getting on the score sheet.
Port Talbot Town did get two more chances before the end of the half when Jordan Pike's free kick on the edge of the area dipped over the wall but was saved well by Lansdown. Keane Watts' effort from distance was asking questions of the keeper again but he made another smart save as PTT took a 1-0 lead going in to half-time.
The intent the home side showed in the opening few minutes turned out to be a real game changer.
Llantwit Major picked up their equaliser minutes in to the second half following a corner. They made their aerial presence felt from this when Anthony Rawlings made contact with the ball, taking a big deflection and beating James Harris who had no chance to react quick enough. The game was now tied at 1-1.
The Major were still dominating this half with another effort testing Harris from distance before they finally grabbed another goal. It was another header this time from another corner in similar circumstances. The ball was whipped in to the box and Sean Williams headed home to put the home side in the lead for the first time in the match.
It took a good 15 minutes of this half before Port Talbot were finally starting to dictate play going forward. Patrick Finneral attacked down the right flank on two occasions but wasn't quite able to get his cross in to the box.
As the minutes started to pass going further in to the half both sides were beginning to waste opportunities with Finneral asking questions of Glyn Davies again. Davies did well to force a goal kick on this opportunity with about 20 left to play.
Llantwit Major came agonisingly close again when a half-volley on the edge of the box had Harris at full stretch who done well to save. Kieran Miller knocked a free-kick from distance in to the box with the next real chance of the game. Matthew Birdsey was able to beat Lansdown to it in goal but the home keeper recovered well to shut down any chance for PTT.
With five minutes left to play the visitors piled on the pressure with waves of attack towards Llantwit Major's goal. There were several aerial battles and away free kicks but this came with no end result for Port Talbot.
Major went up the other end and won another corner with minutes to play and looked dangerous once again. Another powerful header forced James Harris to tip the ball on to the post with what was the last real opportunity of the game for both sides.
Referee Tom Bevan blew for full time and Llantwit Major picked up their first win in the Welsh League this season. Mark Pike's Blues suffered their first away loss of the season with the game finishing 2-1.
Port Talbot go up against another one of the division's new boys in Pontypridd Town next. This one will be taking place at Goytre Unite's Glenhafod Park on Saturday 22nd September with a 2:30pm Kick Off.


text:
Q: log4j2 deleting old archived logs not working I was trying to delete old archived log files automatically via log4j.xml. However, it appears to be not working with my current configuration. I am using rollingfileappender's custom delete.
    <RollingFile name="AppRollingFile" fileName="${logHome}/anow.log"
      filePattern="${logHome}/arch/$${date:yyyy-MM}/app-%d{yyyy-MM-dd}-%i.log.gz">
      <PatternLayout>
        <Pattern>${fullPattern}</Pattern>
      </PatternLayout>
      <Policies>
        <TimeBasedTriggeringPolicy />
        **<SizeBasedTriggeringPolicy size="250 MB"/>**
      </Policies>
      <DefaultRolloverStrategy>
        **<Delete basePath="${logHome}/logs/arch" maxDepth="4">
          <IfFileName glob="*/app-*.log.gz" />
          <IfLastModified age="10d" />
        </Delete>**
      </DefaultRolloverStrategy>
      <ThresholdFilter level="INFO" onMatch="ACCEPT" onMismatch="DENY" />
    </RollingFile>

In the snippet above, I assume that it would remove archive older than 10 days. However, the archives persists. Given that it is February 19 today, it should remove the following files.
sh-4.2$ pwd; ls -lrt
/app/anow/logs/arch/2021-01
total 1441664
-rw-r--r--. 1 1001 2006  10354093 Jan  2 00:00 anow-2021-01-01-1.log.gz
-rw-r--r--. 1 1001 2006  66830028 Jan  3 00:00 anow-2021-01-02-1.log.gz
-rw-r--r--. 1 1001 2006 118353830 Jan  3 01:53 anow-2021-01-03-1.log.gz
-rw-r--r--. 1 1001 2006  19946445 Jan  7 00:00 anow-2021-01-06-1.log.gz
-rw-r--r--. 1 1001 2006  24558293 Jan  8 00:00 anow-2021-01-07-1.log.gz
-rw-r--r--. 1 1001 2006  26325656 Jan  9 00:00 anow-2021-01-08-1.log.gz
-rw-r--r--. 1 1001 2006  24219865 Jan 10 00:00 anow-2021-01-09-1.log.gz
-rw-r--r--. 1 1001 2006  24321364 Jan 11 00:00 anow-2021-01-10-1.log.gz
-rw-r--r--. 1 1001 2006  26148340 Jan 12 00:00 anow-2021-01-11-1.log.gz
-rw-r--r--. 1 1001 2006  28556190 Jan 13 00:00 anow-2021-01-12-1.log.gz
-rw-r--r--. 1 1001 2006  25096070 Jan 14 00:00 anow-2021-01-13-1.log.gz
-rw-r--r--. 1 1001 2006  19412396 Jan 15 00:00 anow-2021-01-14-1.log.gz
-rw-r--r--. 1 1001 2006  36375727 Jan 16 00:00 anow-2021-01-15-1.log.gz
-rw-r--r--. 1 1001 2006  37948374 Jan 17 00:00 anow-2021-01-16-1.log.gz
-rw-r--r--. 1 1001 2006  41469159 Jan 18 00:00 anow-2021-01-17-1.log.gz
-rw-r--r--. 1 1001 2006  46600145 Jan 19 00:00 anow-2021-01-18-1.log.gz
-rw-r--r--. 1 1001 2006  60242290 Jan 20 00:00 anow-2021-01-19-1.log.gz
-rw-r--r--. 1 1001 2006  52262451 Jan 21 00:00 anow-2021-01-20-1.log.gz
-rw-r--r--. 1 1001 2006  58501838 Jan 22 00:00 anow-2021-01-21-1.log.gz
-rw-r--r--. 1 1001 2006  58811286 Jan 23 00:00 anow-2021-01-22-1.log.gz
-rw-r--r--. 1 1001 2006  59832654 Jan 24 00:00 anow-2021-01-23-1.log.gz
-rw-r--r--. 1 1001 2006  62842420 Jan 25 00:00 anow-2021-01-24-1.log.gz
-rw-r--r--. 1 1001 2006  67862898 Jan 26 00:00 anow-2021-01-25-1.log.gz
-rw-r--r--. 1 1001 2006  33771039 Jan 27 00:00 anow-2021-01-26-1.log.gz
-rw-r--r--. 1 1001 2006  75302472 Jan 28 00:00 anow-2021-01-27-1.log.gz
-rw-r--r--. 1 1001 2006  77243585 Jan 29 00:00 anow-2021-01-28-1.log.gz
-rw-r--r--. 1 1001 2006  79226811 Jan 30 00:00 anow-2021-01-29-1.log.gz
-rw-r--r--. 1 1001 2006  97272890 Jan 31 00:00 anow-2021-01-30-1.log.gz
-rw-r--r--. 1 1001 2006 116568611 Feb  1 00:01 anow-2021-01-31-1.log.gz

I don't know what I am missing

redpajama_set_name: RedPajamaStackExchange


text:
Rhizophydium difficile är en svampart som beskrevs av Canter 1954. Rhizophydium difficile ingår i släktet Rhizophydium och familjen Rhizophydiaceae.   Inga underarter finns listade i Catalogue of Life.

Källor

Pisksvampar
difficile

redpajama_set_name: RedPajamaWikipedia


New iPhone 8 Render Shows Vertical Dual-Camera and Rear-Mounted Touch ID Button – Apple Following Samsung's Direction?
This is not the first time that we have seen a dual-camera aligned on an iPhone 8 render. The previous one shows that apart from this optics upgrade, there is more screen real estate but no visual appearance of the home button. However, a new render has popped up and while this one shows the iconic home button, it is present where you will least expect it to be mounted on an Apple-branded mobile device.
It is not 'Apple like' to place a rear-mounted home button on a next-generation iPhone but keep in mind that the tech giant plays around with several prototypes and then decides which one is the best for consumers. Talking about the iPhone 8, the render via Slashleaks shows a dual-camera system that has been incorporated vertically. We get the feeling that this will greatly improve images when you want to capture them with a shallow depth of field and it will be interesting to see the optical zoom capability of the secondary lens.
The screen-to-body ratio of this render is extremely high, meaning that customers that plan to upgrade to the iPhone 8 will have a lot of display to play around with. However, the rear-mounted Touch ID sensor seems out of place for us and that is because the company has never placed it there, even on the first-generation iPhone.
It is more than likely that Apple is playing around with several prototypes, but we highly doubt that this particular version will be chosen as the final product. Our guess is that the home button will be covered beneath the display, thus increasing the screen size considerably.
With a large percentage of the iPhone 7 and iPhone 7 Plus covered by bezels, it unnecessarily increases their size. In addition, the upcoming iPhone 8 will also challenge the likes of Samsung's Galaxy S8 and LG's G6 in terms of bezel-free form factor.
What do you think about this render? We personally hope Apple does not choose this one, but you should tell us what you think in the comments below.