I am starting to write a crate for a specific API. I have read the Modules section of The Rust Reference but I'm unclear if the following 2 file structures are equivalent, and is there a preferable/idiomatic approach?
some-crate/
|- src/
| |- bits.rs
| |- bobs.rs
| |- lib.rs
|- foo/
| |- mod.rs
|- bar/
| |- mod.rs
or
some-crate/
|- src/
| |- bits.rs
| |- bobs.rs
| |- lib.rs
| |- foo.rs
| |- bar.rs
I would like to access my sub-level functions with the following notation some-crate::foo::do_this();
The sub-level modules would require access to common items in bits.rs and bobs.rs.
There will be 4 sub-level modules so not a large file structure to manage.
foo/ and bar/ should be inside of src/. The two options are:
some-crate/ some-crate/
|- src/ |- src/
| |- bar/ | |- bar.rs
| | |- mod.rs | |- bits.rs
| |- foo/ | |- bobs.rs
| | |- mod.rs | |- foo.rs
| |- bits.rs | |- lib.rs
| |- bobs.rs |- Cargo.toml
| |- lib.rs
|- Cargo.toml
Which to use is a matter of taste.
Personally, I use mod.rs once a module gets sub-modules because otherwise foo.rs and foo/ end up visually separated since file viewers usually sort directories before files (see example on right):
some-crate/ some-crate/
|- src/ |- src/
| |- bar/ | |- bar/
| | |- mod.rs | | |- baz.rs
| | |- baz.rs | |- foo/
| |- foo/ | | |- quux.rs
| | |- mod.rs | |- bar.rs
| | |- quux.rs | |- bits.rs
| |- bits.rs | |- bobs.rs
| |- bobs.rs | |- foo.rs
| |- lib.rs | |- lib.rs
|- Cargo.toml |- Cargo.toml
In your first example, foo and bar are not part of your crate at all, since they aren't in the src directory. You may have meant to write it this way:
some-crate/
|- src/
| |- bits.rs
| |- bobs.rs
| |- lib.rs
| |- foo/
| |- mod.rs
| |- bar/
| |- mod.rs
This example and your second example are both equivalent, and I would argue the second way is better if you have small, related modules, and this way would be better if there was more of a logical distinction between them (my brain likes visual separation). If foo and bar eventually had sub-modules themselves, however, then using nested directories would be much preferable to nested mod blocks within a single file.
In your lib.rs, you can also use pub use and pub mod to change how your modules are accessed by others (to a certain extent).
Related
Write two command lines needed to create the following directory tree.
~
|-- bigboy/
| `-- opss/
| |-- user
| `-- teacher
|
`-- arch/
|-- b/
| `-- pr.txt
|
`-- 2022F
Using absolute paths, write one command line to copy directory opss with its files to
directory 2022F. How do you prove this has been done? Use a second command line and its output to show this has been done as expected.
Sample command:
./delete.sh /path/to
|-Path
|- to
|- file1
|- file2
|-location
|- file3
|- file4
|- file5
.
.
|- fileN
Need to delete all the files(file1,file2,file3.....fileN) inside to and location directory using script but do not want to delete to and location directory, need to delete only files in that directory.
In delete.sh you should remove the files inside the directory
d="$1"
rm -rf $d/*
I encountered a folder structure at raymii.org/s/tutorials and I'm not really sure what the symbols `-- mean. Couln't also find any syntax or documentation on how to write such structures.
$ tree -L 2 ExampleProject/
ExampleProject/
|-- build/
|-- CMakeLists.txt
|-- lib/
| `-- googletest
|-- src/
| |-- CMakeLists.txt
| |-- Formula.cpp
| |-- Formula.h
| `-- main.cpp
`-- tst/
|-- CMakeLists.txt
|-- Formula-test.cpp
`-- main.cpp
The symbols represent a polygonal chain leading from the parent directory to the file. '-' represents a horizontal segment of the chain, '`' represents a diagonal segment and '|' represents a vertical segment.
The chain conveys the parent-child relationship of a directory entry and the directory that contains it.
This particular tree shows the root directory ExampleProject which contains a sub directory src which contains a file CMakeLists.txt. And a bunch of other directories and files.
I am, mostly for learning purposes, building a very simple RESTful API for serving a random image or a specific image given an ID. This API will be accessed via a AngularJS client (probably) and will be deployed, together with the API, to my web server. The API and the web client will reside in the same project, that is the same root folder which will actually be a subdirectory on my server accessible via http://foo.com/bar and in the same git repository. Maybe I'll create an Android client later on accessing the same API.
However, I have trouble getting the .htaccess routing/rewriting right. Below follows my proposed directory structure.
root/
|-- bar/
| |-- api/
| | |-- v1/
| | | |-- lib/
| | | | `-- ImageFactory.php
| | | |-- vendor/
| | | | `-- slim/
| | | |-- .htaccess (#1)
| | | |-- composer.json
| | | `-- index.php
| |-- public_html/
| | |-- css/
| | |-- img/
| | | `-- bar/
| | |-- js/
| | | |-- controllers/
| | | |-- directives/
| | | |-- filters/
| | | |-- lib/
| | | |-- services/
| | | |-- vendor/
| | | `-- app.js
| | |-- views/
| | |-- api.php
| | `-- index.html
| `-- .htaccess (#2)
I am thinking that each major rework of the API needs a new version which depends on its own version of Slim, should I change the version over the years.
But what about the .htaccess files? I think that calls to http://foo.com/bar should redirect to public_html/index.html, in other words the JS client app. However, calls to http://foo.com/bar/api/v1 should redirect to public_html/api.php and give the version v1 as a parameter so that api.php can load the correct API app.
How should I write my RewriteEngine rules for .htaccess #1 and #2? Is there something off with my proposed structure? Have I missed something? Please help a developer in need!
To achieve what you want, you only need to add some rules in your /root/bar/.htaccess file.
If by redirect you mean internal rewrite (forward to page without changing url in browser) then you can put this code into your htaccess
RewriteEngine On
RewriteBase /bar/
RewriteRule ^$ public_html/index.html [L]
RewriteRule ^api/v([1-9][0-9]*)$ public_html/api.php?version=$1 [L]
I have a folder structure like this (which is a small snippet):
└── test
└── cases
└── model
├── client
│ ├── socketsTest.coffee
├── server
│ └── socketsTest.coffee
└── shared
└── findersTest.coffee
The question is, how do you list all paths that end in .coffee and don't exist in the client folder?
The following command returns all files matching .coffee that exist in the server folder:
find test -name "*Test.coffee" | egrep '/*server*/'
But what I really need is a regex that matches everything except what's in the client folder.
What is the cleanest way to do this on *nix? The end goal is to return files not inside a client folder, so for the above tree that would be:
$ <find files except those a client folder>
test/cases/model/server/socketsTest.coffee
test/cases/model/shared/findersTest.coffee
I tried doing something like this but no luck:
find test -name "*Test.coffee" | egrep '*model/[^client]*'
You can use the -prune action to ignore directories. -o means "or", so read this as, "if it's named client prune it, otherwise print files named *.coffee".
find test -name client -prune -o -name '*.coffee' -print
Or you can use a double test, which is easier to read but slightly less efficient, since it'll recurse into client/ directories, whereas the first one avoids them entirely.
find test -name '*.coffee' ! -wholename '*/client/*'
I'd second the -prune answer that John Kugelman gives.
Another way to solve this problem using grep is to use the -v option:
find test -name "*Test.coffee" | grep -v client
-v inverts the pattern match, so all the matches that contain "client" are discarded