Tag Info

New answers tagged

3

Most Unix systems don't track file creation times. They track a file's modification time, which is updated each time the file is written to. If the files are written sequentially when they are created (i.e. the first file is fully written before the second file is created) and not modified later, then the order of the modification times will be the same as ...


0

Bash Script that takes one parameter - a filename, and attempts to rename it based on its mime-type using the file command and the system mime.types file: #!/bin/bash # Set the location of your mime-types file here. On some OS X installations, # you may find such a file at /etc/apache2/mime.types; On some linux distros, # it can be found at ...


0

Thanks for all the help, although I haven't been able to get some of these to work. I did, however, successfully implement code I found in an answer to another question! (http://unix.stackexchange.com/a/87476) export DIR=./folder if ls ${DIR}/*.RAW &>/dev/null then echo "Yes!" else echo "No!" fi


-1

Two Bourne Shell Solutions With the Bourne shell (which doesn't support arrays, or shell options like nullglob or failglob) you have to work around the fact that a non-zero exit status or the glob itself will be returned if a glob isn't found. For example: if [ -n "`ls *.RAW 2> /dev/null`" ]; then echo "At least one RAW file found!" else echo ...


0

Your example answer is almost correct. First, you need to separate the testing string ".RAW" from the closing ]: if [ ! -f "*.RAW" ]; You can do shell globbing in this context by taking the asterisk outside of the quotes. So the finished command would be: if [ ! -f *".RAW" ]; However, this approach isn't so useful if you want to use the .RAW files. ...


2

With zsh: files=(*.RAW(DN)) if (($#files)); then echo Yes else echo No fi If you're only interested in regular files (or symlinks to regular files) as your -f implies, that would be: file=(*.RAW(ND-.)) instead. POSIXly: has_regfiles_by_extension() { for ext do for file in .*."$ext" ."$ext" *."$ext"; do [ -f "$file" ] && return ...


1

In filenames, '/' is prohibited because it is a directory separator. That is the only reason. And if you hand-edit a filesystem, you might even be able to create a file with '/' in the name (not recommended, as you won't be able to do much with it). The NUL character cannot be used as part of the filename, because the relevant system calls use C language ...


0

escape the last quote like so: mkdir '$"dollars"&<>\dogs'\'


1

You can't escape a single quote within single quotes. But you can juxtapose multiple quoted strings and they will be concatenated. So just use single quotes for the part not containing a single quote, then append a single quote escaped with a \, like this: mkdir '$"dollars"&<>/dogs'\'


3

Single/double quotes vs. backslash: single quotes and backslashes are equivalent in quoting power. It's a lot more convenient to use single quotes to quote a long string with spaces, tabs, newlines, ()[]*$><?|{}~&;\"`^!# and probably other characters I'm forgetting. But you could achieve exactly equivalent results with just backslashes (beware of ...


2

Printing the null character On many recent shells you can write null character with dollar single quotes format $'\0', hexadecimal format \x00, unicode format \u0000 or \U00000000, or just as you tried with octal: '\0'. The point is that the command has to understand what to do with backslash-escaped characters. For example in case of echo usually one needs ...


3

As you know $var will lead to interpreting the variable. The reason for why the different options work vary: the escape ( \$var ): do NOT interpret the very next character as shell functional character. BUT in some cases: give a special meaning (e.g. \n for newline in some contexts) the single quotes ( '$var' ): everything in single quotes will strictly be ...


2

If file foo has a sibling foo~ the file with a tilde is likely a by-product, backup, or intermediate file for either your compiler or editor. They're usually cleaned up automatically, ignored by your version control, and hidden in guis. Thinks of it as one of those things that most people aren't familiar with and you probably don't want to deal with, ...


5

This is not about "compiling" a program, or even related to coding. This is your text editor creating a backup file. Your text editor (I assume gedit in this case, but correct me if I am wrong) seems to be configured to create a backup file by default. You should observe this behavior with any text file you edit. Check this answer for a solution.


-1

ls ?.* should give you desired results.


1

You have not written which shell you are interested in. GNU Parallel quotes any string in ash bash csh dash fdsh fish fizsh ksh ksh93 mksh pdksh posh rbash rc rush rzsh sash sh static-sh tcsh yash zsh. They each need the strings quoted slightly differently. For details see the 'sub shell_quote_scalar' in ...


2

Unix filenames may contain any character (besides '/' or '\0') so this is actually a shell question; the list of metacharacters that need escaping depend on the shell, and the specific configuration of the shell. You appear to be using bash; other shells will fail if the ? or * glob expressions are left unquoted: $ mkdir test && cd test $ ls $ touch ...


1

Did something happen back in the day that divided the dev crowd into ... camps ...? You may be looking at the chronology backwards.  "Back in the day" the "Unix dev crowd" was all at AT&T Bell Laboratories.  (If you provide enough power to the flux capacitor, you may be able to go back to a time when the "Unix dev crowd" was two people, and they may ...


4

Considering the diversity above, what is the most accepted approach for naming configs? Whatever you want to call them. File extensions don't matter much beyond letting an admin know what the file probably is. A human is probably going to know that *.cfg and *.conf are both probably config files. The *.cnf I've only ever seen with MySQL which is a ...


1

The use of the ~/ at the beginning makes the path absolute since (by any definition) being able to find documents does not depend on where you currently are. However the expansion is done by the shell, not the kernel, so if you are using a shell that does not recognise this syntax ( such as /bin/sh, the original Bourne shell, not the bash alias ), you will ...


-1

The book seems to be taking the view that an absolute path is any path beginning with a /, and a relative path is anything else. You might view .. and $HOME as similar types of tokens. Both need to be substituted, for a path component, before the path resolves to an absolute path.


36

If the author was trying to catch you out by talking about that literal string (without shell expansion) as a path, then it's a relative path. Otherwise: It's an absolute path, because resolving it doesn't depend on the process's current working directory. Relative path always means relative to the process's working directory. Or in the case of symlink ...


3

An absolute path starts at / (what it refers to is fixed), a relative path starts at the current directory (and so what it refers to changes as the current directory changes). Most shells use ~ at the beginning as an abbreviation for the absolute path to the home directory of the current user, i.e., ~/Documents is the directory Documents in the home of the ...


-1

The issues here can still cause range of seriously obscure problems if you are moving files between systems. Unison uses glib and is written in OCAML. The fix was to use the convmv utility which can convert file names from many different formats. It worked, and I seem to have no remaining problems.


45

This is essentially a question about the definition of terms. So for your purposes, the answer is whatever LPIC wants. But we can come to some conclusions based on technical facts: If you passed '~/Documents' to a system call, it would look for a directory named exactly ~, which is not what we mean. So, by the notion of pathnames used by the kernel, this is ...


1

The path could expand to a different location depending on who the user is. Having said that, this is still an absolute path, not a relative path, in my opinion. However, I don't think the definitions of absolute and relative path are so precisely defined. This isn't mathematics. This question doesn't really test understanding, in my opinion, and is ...


16

If your $HOME is /home/white/, ~/Documents (same as $HOME/Documents) is expanded by the shell (see here for an explanation) to /home/white/Documents, which is an absolute path. A relative path is one that does not start with a / (after shell expansion), like ../Documents or foo/bar Some old shells don't expand ~ (the way bash, tcsh, zsh, etc. ... do); they ...


0

grep . *.txt Matches all lines and also shows file names



Top 50 recent answers are included