What Does "./" (Dot Slash) Refer to in Terms of an HTML File Path Location

What does ./ (dot slash) refer to in terms of an HTML file path location?

./ is the the folder that the working file is in:

So in /index.htm ./ is the root directory

but in /css/style.css ./ is the css folder.

This is important to remember because if you move CSS from /index.htm to /css/style.css the path will change.

Why do you need ./ (dot-slash) before executable or script name to run it in bash?

Because on Unix, usually, the current directory is not in $PATH.

When you type a command the shell looks up a list of directories, as specified by the PATH variable. The current directory is not in that list.

The reason for not having the current directory on that list is security.

Let's say you're root and go into another user's directory and type sl instead of ls. If the current directory is in PATH, the shell will try to execute the sl program in that directory (since there is no other sl program). That sl program might be malicious.

It works with ./ because POSIX specifies that a command name that contain a / will be used as a filename directly, suppressing a search in $PATH. You could have used full path for the exact same effect, but ./ is shorter and easier to write.

EDIT

That sl part was just an example. The directories in PATH are searched sequentially and when a match is made that program is executed. So, depending on how PATH looks, typing a normal command may or may not be enough to run the program in the current directory.

what does ./ path specification means?

Generally speaking, the presence of ., .. and / in module names in RequireJS has the same meaning as for HTTP paths.

The presence of ./ in a dependency tells RequireJS to start its search from the current directory. It is extremely useful if what you want is use a module which you know is located in the same directory as the one that needs it. Let's say moduleA needs moduleB and both are in the same directory then moduleA can just require "./moduleB". One advantage of doing this is that you then don't have to worry about where the modules are stored. If you move them around but they are always together in the same directory then moduleA will always find moduleB.

Another thing is that if you require("moduleX") and there are multiple modules named moduleX available, which module are you going to get? Relative paths clarify which one you are going to get.

You ask how you can get rid of the ./ First, I'd ask do you really want to get rid of it? In the scenario I gave where two modules are in the same directory and this relation is meant to be stable, then it does not make sense to get rid of ./. It actually helps people reading the code. If what you are requiring is something like jQuery, which happens to be located in the same directory as another module at some moment but could legitimately be installed somewhere else, and which you would conceivably want to be unique for a given application, then it makes sense to have it be at a global well-known location. To do this, you use paths in your requirejs configuration, like:

paths: {
   'jquery': 'external/jquery-1.9.1'
}

This is an actual piece of code part of an actual application. No matter which module wants jquery, it just issues require("jquery"). It does not have to worry about were jquery is located relative to itself. You can specify a path like this for any module you like, not just jQuery. If jQuery moves to a different location in the future or you want to serve it from a CDN, then this mapping in the snippet above is edited, but require("jquery") still works.

What does / , ./, ../ represent while giving path?

Root directory, current working directory, and parent directory, respectively.

Is there any difference between ./ and / in script src attribute?

Now, I am not super experienced in JavaScript, but I'll let you know what I know.

[...]
<script src="./static/script.js"></script>
[...]
<!--This would reference files in the current folder (where the webpage itself is stored)-->

[...]
<script src="/static/script.js"></script>
[...]
<!--This would reference an absolute path within your webserver, and cannot change dynamically based on from where you load it.-->

Generally speaking, I'd go for ./ when you load it from a file in your current folder (and/or server), whilst doing / seems like an external reference to me, which is also not dynamic. If you happen to move the file (if it was in the same directory as your page), I think JavaScript would also reference the new file instead of complaining about the old one.

I cannot guarantee that any of the info above is correct as I am not a really good JS-Developer, but at least this should help you figure out the syntax a little more.

What does the @ mean inside an import path?

This is done with Webpack resolve.alias configuration option and isn't specific to Vue.

In Vue Webpack template, Webpack is configured to replace @/ with src path:

  const path = require('path');

  ...
  resolve: {
    extensions: ['.js', '.vue', '.json'],
    alias: {
      ...
      '@': path.resolve('src'),
    }
  },
  ...

The alias is used as:

import '@/<path inside src folder>';

path.join vs path.resolve with __dirname

Yes there is a difference between the functions but the way you are using them in this case will result in the same outcome.

path.join returns a normalized path by merging two paths together. It can return an absolute path, but it doesn't necessarily always do so.

For instance:

path.join('app/libs/oauth', '/../ssl')

resolves to app/libs/ssl

path.resolve, on the other hand, will resolve to an absolute path.

For instance, when you run:

path.resolve('bar', '/foo');

The path returned will be /foo since that is the first absolute path that can be constructed.

However, if you run:

path.resolve('/bar/bae', '/foo', 'test');

The path returned will be /foo/test again because that is the first absolute path that can be formed from right to left.

If you don't provide a path that specifies the root directory then the paths given to the resolve function are appended to the current working directory. So if your working directory was /home/mark/project/:

path.resolve('test', 'directory', '../back');

resolves to

/home/mark/project/test/back

Using __dirname is the absolute path to the directory containing the source file. When you use path.resolve or path.join they will return the same result if you give the same path following __dirname. In such cases it's really just a matter of preference.

Why doesn't os.path.join() work in this case?

The latter strings shouldn't start with a slash. If they start with a slash, then they're considered an "absolute path" and everything before them is discarded.

Quoting the Python docs for os.path.join:

If a component is an absolute path, all previous components are thrown away and joining continues from the absolute path component.

Note on Windows, the behaviour in relation to drive letters, which seems to have changed compared to earlier Python versions:

On Windows, the drive letter is not reset when an absolute path component (e.g., r'\foo') is encountered. If a component contains a drive letter, all previous components are thrown away and the drive letter is reset. Note that since there is a current directory for each drive, os.path.join("c:", "foo") represents a path relative to the current directory on drive C: (c:foo), not c:\foo.

What's the difference between --base-href and --deploy-url parameters of angular-cli tool

The answers here are not completely accurate, outdated, and do not give a full explanation.

When should I use each one?

tl;dr In general use --base-href, because --deploy-url

1. is deprecated as of Angular v13
2. will decrease build speed (although, probably not too significant)
3. does not have the benefits of base href in "locating relative template (HTML) assets, and relative fetch/XMLHttpRequests."

If you need the URL to be different than where the assets are placed, the official documentation recommends setting APP_BASE_HREF manually (and differently, e.g. set --base-href to /public/ and APP_BASED_HREF to /users/ if you will serve the Angular files at https://example.com/public/ but you want the web app's URL to be https://example.com/users/)

What's the difference between --base-href and --deploy-url parameters of angular-cli tool?

Above I've already listed 3 differences.

As you have already stated in your question, --base-href sets the <base href> in the index.html (for details see the Mozilla docs and for implications see the community wiki), while --deploy-url prefixes the relative links inside the index.html file.

For example, the following index.html snippet:

<link rel="stylesheet" href="styles.HASH.css">
...
<script src="main.HASH.js" type="module"></script>

With --deploy-url /public/, will be outputted as:

<link rel="stylesheet" href="/public/styles.HASH.css">
...
<script src="/public/main.HASH.js" type="module"></script>

--deploy-url seems to literally just prefix the links, so if you instead did --deploy-url public, the output would be pretty much unusable:

<link rel="stylesheet" href="publicstyles.HASH.css">
...
<script src="publicmain.HASH.js" type="module"></script>

Lastly, if you have a template (HTML) that uses a relative link to an asset, e.g. a header.component.html that contains <img src="assets/logo.jpg">, but you use --deploy-url /public/, the link will not be prefixed and will give you a broken image. This would instead work if <base href="/public/"> is set using --base-href /public/.

---

Related Topics