c++ مریخی و javascript ونوسی و یک ربط بی ربط
حتما بسیاری از شما هنگام برنامه نویسی با زبان C++ هنگام کار کردن با یکی از محیط های برنامه نویسی این زبان با چنین تابع main ای مواجه شده اید:
int main(int argc, char *argv[])
یا این یکی که معادل همان قبلی ست:
int main(int argc char **argv)
و از خودتان پرسیده اید این آرگومان های عجیب غریب به چه دردی می خورند! بعضی وقت ها هم شاید -با اینکه هیچ تاثیری علی الظاهر در برنامه ی شما نداشته- عبارات درون پرانتز را حذف کرده اید و سپس با خیال آسوده تری به کد زنی ادامه داده اید!
اما واقعیت این است که این پارامترها بیخود آنجا نیستند! درحقیقت این پارامترها عاملی هستند که باعث می شوند یک برنامه بتواند با یک خط فرمان مانند CMD در ویندوز یا Terminal در لینوکس و... کار بکند! به طور دقیق تر اتفاقی که می افته اینه که وقتی شما دستور اجرای برنامه تون رو می دید و پارامترهایی رو هم در کنارش می نویسید در خط فرمان، این پارامترها به main اون برنامه ی بخصوص شما ارسال می شن و کاری که برنامه تون می خواد، روشون انچام میشه. به طور دقیق تر:
argv and argc are how command line arguments are passed to main() in C and C++.
argc will be the number of strings pointed to by argv. This will (in practice) be 1 plus the number of arguments, as virtually all implementations will prepend the name of the program to the array.
The variables are named argc (argument count) and argv (argument vector) by convention, but they can be given any valid identifier:
int main(int num_args, char** arg_strings) is equally valid.
They can also be omitted entirely, yielding int main(), if you do not intend to process command line arguments. Try the following program:#include int main(int argc, char** argv){std::cout << "Have " << argc << " arguments:" << std::endl;for (int i = 0; i < argc; ++i) { std::cout << argv[i] << std::endl; } }Running it with ./test a1 b2 c3 will output:Have 4 arguments:./testa1b2c3
شاید حالا بپرسید خب این چه کاریه؟ من اصلا نمی خوام با خط فرمان با برنامه م کار کنم! اصلا برنامه ای که با خط فرمان کار کنه به چه دردی می خوره؟ حتما اون برنامه خیلی مهم نیست! اگر قرار باشه این همه کد بزنم که آخرش با خط فرمان کار کنه که خیلی کسل کننده ست! و از این دست حرف ها!
اما واقعیت دیگر این است که اتفاقا تعداد بسیار زیادی از برنامه هایی که امروزه ساخته می شوند هیچ رابط کاربری گرافیکی ندارند و اتفاقا خیلی هم برنامه های مهمی هستند! یک مثال این موضوع package manager ها خصوصا در دنیای برنامه نویسی هستند. مثلا در زبان javascript با برنامه ی npm می توان packageهای node.js را مدیریت کرد و امروزه بسیاری از وب کار ها همه ی کار و زندگی شان با این برنامه است. :) یا در لینوکس اوبونتو همه باید دائما از package managerای به نام apt استفاده کنند تا برنامه ای را نصب کنند/آپدیت کنند/سرچ کنند/و... .
البته لازم به ذکر است که حتی نیازی نیست یک برنامه 100% بدون رابط گرافیکی باشد تا از دستورات خط فرمان استفاده کند! یک مثال ساده ی آن برنامه ی Microsoft Word است. برای اینکه یک فایل ورد قبلا ذخیره شده را در سیستمتان باز کنید، فرضا روی آن کلیک می کنید، این کلیک کردن شما چیزی نیست جز یک رخداد(اتفاق، event، هرچه نامش را می گذارید) که نام این فایل را در یک دستور خط فرمان به خصوص گذاشته و اجرا می کند تا فایل ورد باز شود!
چند خورده اطلاعات مفید درباره package management systems:
A package management system keeps track of information about software packages: what files go where, and which package owns that file, therefore behaving like a phone directory. Examples of package management systems for Linux include dpkg, rpm and emerge. In Microsoft Windows, "Add/Remove Programs"/"Programs and Features" are like package managers, but use no format (it leaves it up to the program).
یک سوال جالب در وب که سوال خودمم بود:
I've never understood why there isn't a "meta-package manager" that gives you one OS-and-platform-neutral CLI tool for invoking whatever the most relevant package management tooling would be, and then polyfills in the differences.
At a base level, I want to just not have to care whether I need to "brew install", "gem install", or "npm install -g" something: just give me one namespace and put everything I need in it once. If the tool could do just that, I'd be sold.
However, I can't see why there couldn't be a more-complex namespace-mapping database, such that I could e.g. export an installed-above-baseline package-list from Ubuntu and import it into OSX, or Windows+Cygwin, to get equivalent effects. I wouldn't need the same versions of anything, necessarily; just the same commands and libraries.
Package Management Systems: A Brief Overview
Most package systems are built around collections of package files. A package file is usually an archive which contains compiled binaries and other resources making up the software, along with installation scripts. Packages also contain valuable metadata, including their dependencies, a list of other packages required to install and run them.
While their functionality and benefits are broadly similar, packaging formats and tools vary by platform:
| Operating System | Format | Tool(s) |
|---|---|---|
| Debian | .deb |
apt, apt-cache, apt-get, dpkg
|
| Ubuntu | .deb |
apt, apt-cache, apt-get, dpkg
|
| CentOS | .rpm |
yum |
| Fedora | .rpm |
dnf |
| FreeBSD | Ports, .txz
|
make, pkg
|
Update Package Lists
Most systems keep a local database of the packages available from remote repositories. It's best to update this database before installing or upgrading packages. As a partial exception to this pattern, yumand dnf will check for updates before performing some operations, but you can ask them at any time whether updates are available.
| System | Command |
|---|---|
| Debian / Ubuntu | sudo apt-get update |
sudo apt update |
|
| CentOS | yum check-update |
| Fedora | dnf check-update |
| FreeBSD Packages | sudo pkg update |
| FreeBSD Ports | sudo portsnap fetch update |
A package management system does much more than one-time installation of software. It also provides tools for upgrading already-installed packages. Package repositories help to ensure that code has been vetted for use on your system, and that the installed versions of software have been approved by developers and package maintainers.
When configuring servers or development environments, it's often necessary look beyond official repositories. Packages in the stable release of a distribution may be out of date, especially where new or rapidly-changing software is concerned.
لینک های مفید برای مطالعه بیشتر:
