Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
I already know what it does: It simply goes one directory or folder backwards.
But what's mysterious for me are those two dot.
cd.. #it has the same function as popd with the difference that it changes the
#current working directory
If someone tell me what is the philosophy of putting those two Dots, i would really appreciate it.
.. in filesystem paths represents a given path's parent path.
Without an explicit path preceding the .., the implied path is the current [working] directory, so the .. therefore refers to the current directory's parent directory.
In short: cd with an argument of .. changes to the current directory's parent directory, i.e., the directory one level above in the directory hierarchy.
Shell-specific use of .. with cd:
The legacy command processor, cmd.exe ("Command Prompt") - seemingly with the internal cd command specifically (see Mofi's comments on the question) - considers an . character to implicitly start the cd command's argument.
Therefore, separating the cd command from the .. argument with a space character, as usual, isn't necessary; that is, instead of cd .. you can type cd.., which is a shortcut that users of cmd.exe have grown accustomed to over the years.
PowerShell allows . characters to be used in command names, so submitting cd.. does not invoke the cd command (a built-in alias for the Set-Location cmdlet) with argument .. - instead, it looks for a command literally named cd..
To accommodate cmd.exe users who are accustomed to the cd.. shortcut, PowerShell comes with a parameter-less function literally named cd.., so that submitting cd.. as a command in PowerShell effectively works the same as in cmd.exe.
However, note that only cd.. works, not also specifying additional components; that is, something like cd..\Foo (which works in cmd.exe) fails.
Get-Command cd.. | Format-List shows information about this function, which reveals that it simply calls Set-Location .., which is PowerShell's equivalent of cmd.exe's cd ..
These two dots mean "One upper level in the directory".
cd specifies to change the directory and .. means "upper level". So, cd.. means exactly what you stated in your question.
Example: let's say you are in the folder C:\x\y. If you type cd.., you'll be on C:\x
Related
I've been referencing files in my scripts with a period to indicate the current execution directory of the script, such as ".\images\test.png" but I've discovered that I could also point to the same file with $PSScriptRoot\images\test.png.
Is there an argument to be made for one over the other? When using the PS ISE, the former requires that I CD into my script directory before running code, but the scripts will normally be run automatically so the PWD should always be localized in scope. Is there another case I'm not considering?
ED: I suppose I should have specified that I am asking in the case of an independent script that is executed in isolation (it's invoked directly and does not invoke other scripts), which probably leads to the edge case of the current location and location of the current script are one in the same. In less specific conditions that I failed to consider, I can see more divergence.
The direct answer to your question as to "is there a difference" is yes, there is a substantial difference.
The difference is that . is a reference to the current location. If the current location is a different location than where the script is, then it will not be the same as $PSScriptRoot. For example:
PS C:\> C:\Scripts\Test-Script.ps1
Inside Test-Script.ps1, . will refer to C:\ but $PSScriptRoot will refer to C:\Scripts.
This question already has answers here:
How can I set a shorthand alias for a variable?
(2 answers)
Closed 6 years ago.
Trying to store some long pathways shortcut for all-time usage
for example Im often skipping to
cd C:\Users\xx\Dropbox\yy\folder_name
and I first tried to store it with New-Alias command like:
name: dropbox
value: cd C:\Users\xx\Dropbox\yy\folder_name
(also tried just the path way i.e C:\Users\xx\Dropbox\yy\folder_name)
But it won't work.
I've also created a profile and tried to edit the .ps1 file with:
New-Item alias:dropbox -Value "Set-Location \C:\Users\xx\Dropbox\yy\folder_name"
but this won't work either "search-path not correct" or something.
Anyone have an easy solution?
You could use a script like this:
if($args[0] -eq "dir1")
{
cd c:\projects\myProject
}
If you name it "ccd.ps1" and put it in your path, it should work to just type "ccd dir1"
At least it's a simple, understandable solution...
With mine I actually use a lookup in a config file with a dozen or so paths and shortcut names, but most people wouldn't mind just editing the .ps1.
I would like to move files filtered using wildcards to subfolders, however perforce move does not accept my usage of the wild card.
given this structure
filea_mk1.txt
fileb_mk2.txt
mk1/
mk2/
to move all files some thing like p4 move ./... ./mk1/... works, however when replacing the selected file to use wild cards I get:
p4 edit filea_mk1.txt
p4 move *_mk1*.* ./mk1/...
Usage: move [-c changelist#] [ -f ] [ -k ] [-t type] from to
Missing/wrong number of arguments.
I have thought about using p4 fstat as that does accept the wildcards, and could then pass filenames into to xargs.
p4 fstat *_mk1*.*
However I can not get the -A options correct to only show client names.
TL;DR
Is there a way to filter *_mk1*.* into the mk1 folder and *_mk2*.* into the mk2 folder, using perforce commands?
Instead of this:
p4 move *_mk1*.* ./mk1/...
Do this:
p4 move "*_mk1*.*" "mk1/*_mk1*.*"
Note the double quotes to keep the shell from expanding the asterisks.
Alternatively, this simpler form will probably work fine unless the paths are trickier than your example makes them appear:
p4 move ..._mk1... mk1/..._mk1...
I believe that what's happening here is that your operating system shell is expanding the asterisk wildcards in your command, so the actual command that the Perforce server is seeing is:
`p4 move filea_mk1.txt fileb_mk1.txt ./mk1/...`
and that command has three file-spec arguments, rather than the expected two file-spec arguments, hence the Usage: message that you receive.
By using operating-system filenames (*_mk1*.* and ./mk1/...), you are providing the file-spec arguments in what Perforce calls "local" syntax.
But this causes your operating system shell to think it should expand the wildcards, when what you want is to have the Perforce server expand the wildcards.
You can try using different quoting strategies for your arguments, to defeat that local wildcard expansion, but this is a situation where you can benefit from using one of the other forms of file-spec syntax, either "client" syntax" or "depot" syntax.
For example, suppose that your client root is actually located in a section of the depot that begins with the path //depot/projects/project1/main/.
Then, you could specify your command as:
`p4 move //depot/projects/project1/main/*_mk1*.* //depot/projects/project1/main/mk1/*_mk1*.*`
In this case, these file-spec arguments will not be seen as syntax that your operating-system shell should expand, so it will leave the arguments alone and pass them unaltered to the server, so that the Perforce server can perform the wildcard expansion, rather than allowing your shell to perform the wildcard expansion.
Note that I also re-specified your wildcard expansion slightly. The Perforce move command, like the integrate command and several other commands, is typically happiest if the "wildcards on the left side" match up with the "wildcards on the right side", so that when it is constructing new destination file names for the files being moved, it can replace the wild-carded elements 1-1 with the wild-carded elements from the source file names.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
When executing a C-program, we have to type a '.' token and a '/' token together followed by our program name:
./program
What do each of the these tokens mean? Why do they need to be together to work?
The ./ syntax just refer to the current directory (Actually . is the current directory while / is the path separator). This is needed because the shell will look into folders specified in $PATH environment variable for executables. Since the program is in the current directory which is not inside PATH by default you need to specify the folder you are running it from.
Actually, this has nothing to do with C. This value is simply passed along to the operating system and used to locate a file.
But on Windows, it doesn't appear to have much meaning at all. . is the current directory and the / is simply the path separator between the current directory and program. Since the OS defaults to the current directory, it refers to the same path as just program.
. means current path
.. means parent.
/ means root or path separator. Depends on Unix/Windows/Mac
./ means current path and relates, towards RHS.
./Program means PWD and Program as Directory or Location.
I am new to UNIX and when I was reading a book about UNIX, I came across following two problems that I didn't understand. I would really appreciate your help.
1) Look up the man page for the file command, and then use it on all files in the /dev directory. Can you group these files into two categories?
2) Run the tty command, and note the device name of your terminal. Now use this device name(/dev/pst/6) in the command cp /etc/passwd /dev/pts/6. what do you observe?
Fair question really... it's so easy for us to take so much for granted.
To read the manual page for the command called file, just type...
man file
...which will present a lot of information that will probably be quite confusing, but you'll get used to this stuff pretty quick if you keep at it. Crucially, file is a program that tries to categorise the files you ask it to. If you type...
file /dev/*
...that will do what the question asked, and invoke file with a list of the files in the /dev/ subdirectory. The list is actually prepared by the "shell" program that you're typing into, which then executes the file program and passes it the list. file then outputs some description of the files. On my computer, and where [SHELL-PROMPT] will be different on your computer, I typed file /dev/* and part of the output looked like:
[SHELL-PROMPT] file /dev/*
...lots of stuff...
/dev/cevt: character special (255/176)
/dev/console: character special (5/1)
/dev/core: symbolic link to `/proc/kcore'
/dev/cpqci: character special (10/209)
/dev/cpqhealth: directory
/dev/crom: character special (255/180)
...lots of stuff...
/dev/md8: block special (9/8)
/dev/md9: block special (9/9)
/dev/mem: character special (1/1)
/dev/mice: character special (13/63)
/dev/mouse0: character special (13/32)
/dev/mptctl: character special (10/220)
/dev/net: directory
/dev/nflog: character special (36/5)
/dev/null: character special (1/3)
/dev/parport0: character special (99/0)
...lots of stuff...
There's a filesystem entry for each directory/file combination (known as a path) in the left column, and file is describing the content in the right. Those descriptions may not make a lot of sense, but you can see that some patterns: some entries are "block special", others "character special", some are directory which implies you may find more files underneath (i.e. ls /dev/net/*). The numbers after "special" files are just operating system identifiers to differentiate the files mentioned. The import of this is that input and output from some devices connected to the computer is being made possible as if the device was a file in the filesystem. That "file" abstraction is being used as a general model for input and output. So, /dev/tty for example is tty - or terminal - device. Any data you try to read from there will actually be taken from the keyboard you're using to type into the shell (in the simple case), and anything you write there will become visible in the same terminal you're typing into. /dev/null is another interesting one: you can read and write from it, but it's an imaginary thing that never actually provides data (just indicates and End-of-File condition, and throws away any data written into it). You can keep reading from /dev/random and it will produce random values each time... good if you need random numbers or file content for encryption or some kind of statistical work.
2) Run the tty command, and note the
device name of your terminal. Now use
this device name(/dev/pst/6) in the
command cp /etc/passwd /dev/pts/6.
what do you observe?
By typing "tty" you can ask for the device representing your terminal...
[SHELL-PROMPT] tty
/dev/pts/11
But, I just said /dev/tty is another name for the same thing, so there's normally no need to use the "tty" program to find this more specific name. Still, if you create a couple terminal windows to your host, and type tty in each, you will see that each shell is connected to a different pseudo-terminal device. Still, each shell - and program run from the shell - can by default also refer to its own terminal input and output device as /dev/tty... it's a convenient context-sensitive name. The command...
cp /etc/passwd /dev/pts/6
...where you replace 6 with whatever your tty program really reported (e.g. 11 in my case), does the same thing as...
cp /etc/passwd /dev/tty
...it just reads the contents of the file /etc/passwd and writes them out on your screen. Now, the problem is that /etc/password looks like a lot of unintelligible junk to the average person - it's no wonder you couldn't make sense of what was happening. Try this instead...
echo "i said hello" > /tmp/hello.file
cp /tmp/hello.file /dev/tty
...and you'll see how to direct some specific, recognisable content into a new file (in this case putting it in the tmp "temporary" directory (the file will disappear when you reboot your PC), then copying that file content back to your screen.
(If you have logged on in two terminal windows, you can even go into one shell and copy the file to the /dev/pts/NN device reported by the other shell, effectively sending a message to the other window. You can even bypass the file and echo 'boo' > /dev/tty/NN. You'll only have permissions to do this if the same userid is logged into both windows.)